CN109923879B - Core network overload control for control plane evolution packet system - Google Patents

Abstract

Embodiments of the present disclosure describe methods and apparatus for mechanisms to prevent overload of a core network for control plane data transport.

Description

Core network overload control for control plane evolution packet system

RELATED APPLICATIONS

This application claims priority to U.S. provisional application No. 62/402,514 filed on 30/9/2016, the entire contents of which are incorporated herein by reference.

Technical Field

Embodiments of the present disclosure relate generally to the field of networks and, more particularly, to an apparatus, system, and method for core network overload control for a control plane evolved packet system.

Background

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of the embodiments. However, it will be apparent to one having ordinary skill in the art having had the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the respective embodiments with unnecessary detail.

The rapid expansion of network communications from cellular internet of things ("CIoT") deployments may result in a large amount of relatively small data transmissions over the core network ("CN") of an evolved packet system ("EPS"). Two mechanisms have been developed to improve the efficiency of these communications. The first mechanism is called user plane CIoT EPS optimization, which is based on user plane transmission of user data. The second mechanism, referred to as control plane CIoT EPS optimization, transports user data via a mobility management entity ("MME") by encapsulating the user data in a non-access stratum ("NAS") message.

Disclosure of Invention

According to a first aspect of the present application, one or more computer-readable media are provided having instructions stored thereon that, when executed by one or more processors, cause a mobility management entity ("MME") to: processing a control plane service request ("CPSR") message carrying an evolved packet service bearer identity ("EBI") for identifying an evolved packet service ("EPS") bearer of a user equipment; detecting an overload condition in the network; determining that an EPS bearer is not fixed to a Control Plane (CP) -only connection; and initiating establishment of an S1-U bearer for the user equipment based on the detection of the overload condition and the determination that the EPS bearer is not fixed to the CP-only connection.

According to a second aspect of the present application, there is disclosed processing circuitry to be implemented in an evolved node B ("eNB"), the processing circuitry configured to cause the eNB to: processing a first message from a user equipment ("UE"), the first message including data to be sent over a control plane connection via a mobility management entity ("MME"); determining whether the MME is overloaded; determining, based on the first message, whether data is to be sent by a bearer that is fixed to the control plane only connection; forwarding the first message to the MME if it is determined that the data is to be sent by a bearer that is not fixed to the control plane only connection; if it is determined that data is to be sent by a bearer fixed to the control plane-only connection, a radio resource control ("RRC") connection reject message carrying a backoff timer value is sent to the UE to prevent the UE from sending additional uplink data over the control plane connection.

According to a third aspect of the present application, one or more computer-readable media are provided having instructions stored thereon that, when executed by one or more processors, cause a user equipment ("UE") to: generating and transmitting a first control plane ("CP") data message to transmit data over a control plane connection; receiving a radio resource control ("RRC") reject message having a backoff timer value in response to the first CP data message when the network is overloaded; setting a CP backoff timer based on a backoff timer value in response to the RRC reject message; and generating and transmitting a second CP data message when the CP backoff timer expires.

According to a fourth aspect of the present application, there is provided processing circuitry to be implemented within a mobility management entity ("MME"), the processing circuitry configured to cause the MME to: processing a control plane service request ("CPSR") message carrying an evolved packet service bearer identity ("EBI") for identifying an evolved packet service ("EPS") bearer of a user equipment; determining that the EPS bearer corresponds to a PDN connection that is not set to a Control Plane (CP) only; detecting an overload condition in the network; initiating establishment of an S1-U bearer for the user equipment based on the detection of the overload condition and the determination that the EPS bearer corresponds to a PDN connection that is not set to CP only; and when an overload condition is detected, sending a backoff timer value to a user equipment ("UE") within an S1-AP initial context setup request, ICSR, message to prevent the UE from sending further uplink data over the control plane connection.

Drawings

The embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate the description, like reference numerals designate like structural elements. Embodiments are shown by way of example, and not by way of limitation, in the figures of the accompanying drawings.

FIG. 1 illustrates an architecture of a system according to some embodiments.

Figure 2 illustrates a control plane protocol stack in accordance with some embodiments.

FIG. 3 illustrates a flow according to some embodiments.

Fig. 4 shows a flow according to other embodiments.

Fig. 5 illustrates an example operational flow/algorithm structure of a user equipment according to some embodiments.

Fig. 6 illustrates an example operational flow/algorithm structure of an access node according to some embodiments.

Figure 7 illustrates an example operational flow/algorithm structure of a mobility management entity in accordance with some embodiments.

FIG. 8 illustrates an apparatus according to some embodiments.

FIG. 9 illustrates hardware resources according to some embodiments.

Detailed Description

In the following detailed description, reference is made to the accompanying drawings which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments which may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure.

Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. The operations described may be performed in a different order than the described embodiments. Various additional operations may be performed or the described operations may be omitted in further embodiments.

For the purposes of this disclosure, the phrases "a or B", "a and/or B", and "a/B" mean (a), (B), or (a and B).

The description may use the phrases "in one embodiment" or "in an embodiment," which may each refer to one or more of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are synonymous.

Fig. 1 illustrates an architecture of a system 100 of networks according to some embodiments. System 100 is shown to include a User Equipment (UE) 104. The UE104 may be a smartphone (e.g., a handheld touchscreen mobile computing device that may be connected to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a Personal Data Assistant (PDA), a pager, an internet of things ("IoT") device, a smart sensor, a laptop computer, a desktop computer, a wireless handheld device, or any computing device that includes a wireless communication interface.

In embodiments where the UE104 includes an IoT device, it may also include a network access layer designed for low power IoT applications that employ short-term UE connections. IoT UEs may employ technologies such as machine-to-machine ("M2M") or machine type communication ("MTC") for exchanging data with MTC servers or devices via public land mobile networks ("PLMNs"), proximity-based services ("ProSe") or device-to-device ("D2D") communications, sensor networks, or IoT networks. The M2M or MTC data exchange may be a machine initiated data exchange. An IoT network describes interconnected IoT UEs that may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-term connectivity. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

The UE104 may be configured to connect (e.g., communicatively couple) an access node 108 of a radio access network ("RAN") 110 via a Uu interface. RAN 110 may be, for example, an evolved universal terrestrial radio access network ("E-UTRAN") (in which case access node 108 may be an evolved node B ("eNB")), a next generation RAN ("NG RAN") (in which case access node 108 may be a next generation node B ("gNB")), or some other type of RAN. The UE104 may utilize an air interface protocol to effectuate communicative coupling over the Uu interface. The air interface protocol may be consistent with a cellular communication protocol, such as a global system for mobile communications ("GSM") protocol, a code division multiple access ("CDMA") network protocol, a push-to-talk ("PTT") protocol, a cellular PTT ("POC") protocol, a universal mobile telecommunications system ("UMTS") protocol, a 3GPP long term evolution ("LTE") protocol, a fifth generation ("5G") protocol, a new radio ("NR") protocol, and so forth.

The access node 108 may terminate the air interface protocol and may be a first point of contact for the UE 104. In some embodiments, access node 108 may implement various logical functions of RAN 110, including, but not limited to, radio network controller ("RNC") functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

To establish a connection with the access node 108, the UE104 may perform a number of operations. The first operation may include, for example, synchronizing with a frequency to identify an operator to which the UE104 is to connect. After synchronization, the UE104 may read and process information blocks, e.g., master information blocks ("MIB") and system information blocks ("SIB"), to obtain information for accessing the cell provided by the access node 108. The UE104 may then perform a random access procedure to request the access node 108 to provide the UE104 with temporary resources for initial communication. After the random access procedure, the UE104 may establish a radio resource control ("RRC") connection by sending an RRC connection request message, which may also be referred to as RRC message 3; receiving an RRC connection setup message; and sending an RRC connection setup complete message, which may be referred to as RRC message 5. After sending the RRC connection setup complete message, the UE104 may be in an RRC-connected state.

In some embodiments, the RRC connection request message may include a UE identity (which may include a temporary mobile subscriber identity ("TMSI") or a random value) and a connection establishment cause. In some embodiments, the RRC connection setup message may include a default configuration for the first signaling radio bearer (SRB1), as well as other configuration information related to, for example, physical uplink shared channel ("PUSCH"), physical uplink control channel ("PUCCH"), physical downlink shared channel ("PDSCH"), channel quality indicator ("CQI") reports, sounding reference signals, antenna configuration, scheduling requests, and so forth. In some embodiments, the RRC connection setup complete message may include information about the selected PLMN and UE-specified NAS layer information.

In accordance with some embodiments, UE104 may be configured to communicate with other UEs or access nodes 108 using orthogonal frequency division multiplexing ("OFDM") communication signals over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an orthogonal frequency division multiple access ("OFDMA") communication technique (e.g., for downlink communications) or a single carrier frequency division multiple access ("SC-FDMA") communication technique (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signal may include a plurality of orthogonal subcarriers.

In some embodiments, the downlink resource grid may be used for downlink transmissions from the access node 108 to the UE104, while uplink transmissions may use similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is a physical resource in the downlink in each slot. This time-frequency plane representation is a common practice of OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in the resource grid is denoted as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this may represent the minimum amount of resources that can currently be allocated. There are several different physical downlink channels transmitted using such resource blocks.

The PDSCH may carry user data and higher layer signaling to the UE 104. The physical downlink control channel ("PDCCH") may carry, among other things, information about the transport format and resource allocations related to the PDSCH channel. It may also inform the UE104 of transport format, resource allocation, and hybrid automatic repeat request ("H-ARQ") information related to the uplink shared channel. In general, downlink scheduling (assigning control and shared channel resource blocks to UEs 104 within a cell) may be performed at the access node 108 based on channel quality information fed back from the UEs 104. The downlink resource allocation information may be sent on a PDCCH used for (e.g., allocated to) the UE 104.

The PDCCH may use control channel elements ("CCEs") to transmit control information. The PDCCH complex-valued symbols may first be organized into quadruplets before being mapped to resource elements, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements, respectively, referred to as resource element groups ("REGs"). Four quadrature phase shift keying ("QPSK") symbols may be mapped to each REG. The PDCCH may be transmitted using one or more CCEs, depending on the size of downlink control information ("DCI") and channel conditions. Four or more different PDCCH formats with different numbers of CCEs may be defined in LTE (e.g., aggregation level, L ═ 1, 2, 4, or 8).

Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments may utilize an enhanced physical downlink control channel ("EPDCCH") that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced control channel elements ("ECCEs"). Similar to the above, each ECCE may correspond to nine sets of four physical resource elements each, referred to as enhanced resource element groups ("EREGs"). In some cases, ECCE may have other numbers of EREGs.

RAN 110 may be communicatively coupled to core network ("CN") 116 via an S1 interface. In some embodiments, communications over the S1 interface may be compatible with the S1 application protocol (S1 AP). In embodiments, CN 116 may be an evolved packet core ("EPC") network, a next generation packet core ("NPC") network, or some other type of CN. In this embodiment, the S1 interface may be divided into two parts: an S1-U interface that carries traffic data between the access node 108 and a serving gateway ("S-GW")/packet gateway ("P-GW") 120; and S1-mobility management entity ("MME") interface, which is a signaling interface between access node 108 and MME 124. Although shown together in fig. 1, the S-GW and P-GW may alternatively be implemented in different devices, servers, etc.

In this embodiment, the CN 116 includes an S-GW/P-GW120, an MME 124, and a service capability exposure function ("SCEF") 128. The MME 124 may be similar in function to the control plane of a conventional serving general packet radio service ("GPRS") support node ("SGSN"). MME 124 may manage mobility aspects in access such as gateway selection and tracking area list management.

The S-GW of S-GW/P-GW120 may terminate the S1-U interface towards RAN 110 and may route data packets between RAN 110 and CN 116. Furthermore, the S-GW may be a local mobility anchor point for inter-RAN node handover, and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

The P-GW of the S-GW/P-GW120 may terminate the SGi interface towards the packet data network ("PDN") 132. The P-GW may route data packets between the CN 116 and an external network (e.g., PDN 132). The PDN 132 may include an application server ("AS") 136 (alternatively referred to AS an application function ("AF")) communicatively coupled with the CN 116 via an internet protocol ("IP") interface. In general, the application server 136 may be an element that provides applications that use IP bearer resources with the CN 116 (e.g., UMTS Packet Service (PS) domain, LTE PS data services, etc.). The application server 136 may also be configured to support one or more communication services (e.g., voice over internet protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UE104 via the CN 116.

The SCEF 128 may be a device used to securely expose the security and capabilities provided by the 3GPP network interface. SCEF 128 may perform various functions that may provide, for example, entities external to a 3GPP network the ability to discover the service capabilities of components within the 3GPP network. These functions may include, for example, authentication and authorization, policy enforcement, vouching, billing, access, abstraction, and the like. The SCEF 128 may protect entities of the CN 116 from requests beyond the permissions provided in the service level agreement with the third party service provider.

The components of system 100 can cooperate to provide one or more PDN connections connecting UE104 to PDN 132. The PDN connection may be established with the creation of a default EPS bearer. The default EPS bearer may be associated with a default quality of service ("QoS"). If the PDN connection is to handle a type of service that requires specific QoS treatment, e.g., voice or video streaming, an additional EPS bearer, called a dedicated EPS bearer, may be created and associated with a specific QoS.

The PDN connection may be an SCEF connection routed through SCEF 128 or an SGi connection routed through S-GW/P-GW 120. Fig. 1 shows different routing paths over various PDN connections, which may be used for CIoT optimization. Path 1 may be used for data routing over SCEF connections using control plane CIoT EPS optimization. This connection is always fixed to the (pined to) control plane (in other words, it cannot switch to the user plane). Path 2 may be used for data routing over SGi connections using control plane CIoT EPS optimization. The connection may or may not be fixed to the control plane. Path 3 may be used for data routing over SGi connections using user plane EPS CIoT optimization (or legacy S1-U).

In some cases, if a CP fixed connection is used, data may be transmitted over both the user plane ("UP") and the control plane ("CP"). For example, data may be routed via paths 1 and 3, or via paths 1 and 2 within the same RRC connection. If the UE104 is in the RRC-connected state, it may only make path 2 connections or path 3 connections active, but not both paths active at the same time (for the same or different PDNs), and may only switch from path 2 to path 3 (but not vice versa).

Figure 2 illustrates a control plane protocol stack in accordance with some embodiments. In this embodiment, control plane 200 is shown as a communication protocol stack between UE104, AN 108, and MME 124.

The physical ("PHY") layer 204 may transmit/receive information over one or more air interfaces for use by the media access control ("MAC") layer 208. The PHY layer 204 may also perform link adaptation or adaptive modulation and coding ("AMC"), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers such as the RRC layer 220. PHY layer 204 may further perform error detection for transport channels, forward error correction ("FEC") encoding/decoding for transport channels, modulation/demodulation for physical channels, interleaving, rate matching, mapping to physical channels, and multiple-input multiple-output ("MIMO") antenna processing.

The MAC layer 208 may perform mapping between logical channels and transport channels, multiplexing MAC service data units ("SDUs") from one or more logical channels onto transport blocks for delivery to the PHY layer 204 via transport channels, demultiplexing MAC SDUs from transport blocks delivered from the PHY layer 204 via transport channels into one or more logical channels, multiplexing MAC SDUs onto transport blocks, scheduling information reporting, error correction by hybrid automatic repeat request ("H-ARQ"), and logical channel prioritization.

The radio link control ("RLC") layer 212 may operate in a variety of operating modes, including: transparent mode ("TM"), unacknowledged mode ("UM"), and acknowledged mode ("AM"). The RLC layer 212 may perform transmission of upper layer protocol data units ("PDUs"), error correction by automatic repeat request ("ARQ") of AM data transmissions, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transmissions. The RLC layer 212 may also perform re-segmentation of RLC data PDUs for AM data transmission, re-ordering RLC data PDUs for UM and AM data transmission, detecting duplicate data for UM and AM data transmission, discarding RLC SDUs for UM and AM data transmission, detecting protocol errors for AM data transmission, and performing RLC re-establishment.

The packet data convergence protocol ("PDCP") layer 216 may perform header compression and decompression of IP data, maintain PDCP sequence numbers ("SNs"), perform in-order delivery of upper layer PDUs in re-establishing lower layers, eliminate duplication of lower layer SDUs in re-establishing lower layers of a radio bearer mapped onto the RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based data discard, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).

The primary services and functions of the RRC layer 220 may include broadcasting of system information (e.g., included in a master information block ("MIB") or a system information block ("SIB") related to a non-access stratum ("NAS")), broadcasting of system information related to an access stratum, paging of an RRC connection between the UE and the E-UTRAN, establishment, maintenance, and release (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance, and release of point-to-point radio bearers, security functions including key management, inter-radio access technology ("RAT") mobility, and measurement configuration for UE measurement reporting. The MIB and SIBs may include one or more information elements ("IEs"), each of which may include a separate data field or data structure.

The RRC layer 220 and the following layers may be collectively referred to AS an AS. The UE104 and the AN 108 may utilize a Uu interface (e.g., LTE-Uu interface) to exchange control plane data via a protocol stack including the PHY layer 204, MAC layer 208, RLC layer 212, PDCP layer 216, and RRC layer 220.

NAS layer 224 may form the highest layer of the control plane between UE104 and MME 124. The NAS layer 224 may support mobility and session management procedures for the UE104 to establish and maintain an IP connection between the UE104 and the P-GW.

The S1 application protocol ("S1-AP") layer 228 may support the functionality of the S1 interface and include the basic procedure ("EP"). AN EP can be a unit of interaction between AN 108 and a CN 116. The S1-AP layer service may include two groups: UE-associated services and non-UE-associated services. These services perform functions including, but not limited to: E-UTRAN radio Access bearer ("E-RAB") management, UE capability indication, mobility, NAS signaling transport, RAN information management ("RIM") and configuration transport.

Stream control transmission protocol ("SCTP") layer (alternatively referred to as SCTP/IP layer) 232 may ensure that signaling messages are reliably communicated between AN 108 and MME 124 based on the IP protocol supported by IP layer 236. The L2 layer 240 and the L1 layer 244 may refer to communication links (e.g., wired or wireless) used by the AN 108 and MME 124 to exchange information.

The AN 108 and MME 124 may utilize the S1-MME interface to exchange control plane data via a protocol stack including L1 layer XV11, L2 layer XV12, IP layer XV13, SCTP layer XV14, and S1-AP layer XV 15.

In conventional systems, the eNB may be informed by the MME of the overload situation of the CN through S1-AP, and the eNB may make a decision to reject any UE' S RRC connection request. However, the eNB may still not know whether the RRC connection request is for transmitting data via the control plane or the user plane. Thus, embodiments described herein provide a way in which the access node 108 can distinguish whether an RRC connection is used for the user plane (e.g., a service request or an extended service request) or the control plane (e.g., a control plane service request).

In some embodiments, the UE104 may support only control plane CIoT EPS optimization. In these embodiments, there are four alternative mechanisms by which information about whether the RRC connection is for the user plane or the control plane may be provided. In alternative 1, the access node 108 may parse the NAS message received within RRC message 5 (rather than transparently relay the NAS message to the MME 124) to determine whether it is a control plane service request. In alternative 2, a new CP data indication may be defined in message 3 (e.g., RRC connection request). The new CP data indication may be added through a new information element or through a new establishment cause. In alternative 3, a new logical channel identification ("LCID") for RRC message 3 (e.g., RRC connection request) may be used. In alternative 4, a new CP data indication IE may be defined in RRC message 5 (e.g., RRC connection setup complete).

The RRC connection request may be defined as follows in order to add a new CP data indication through a new information element.

RRC connection request

As described above, the RRC connection request message is used to request establishment of an RRC connection. The RRC connection request message may be sent from UE104 to RAN 110 on signal radio bearer 0 ("SRB 0"); having a transparent mode ("TM") radio link control-service access point ("RLC-SAP"); and transmitted in a logical channel such as the common control channel ("CCCH"). In some embodiments, the RRC connection request message may have an abstract syntax notation 1 ("asn.l") structure as shown below.

RRC connection request message

As shown, the RRC Connection request message may include a CP Data (CP-Data) field and a CP-Only-Connection (CP-Only-Connection) field. These fields may be enumerated type fields. A true (true) value of the CP data field may indicate that an RRC connection may be established for the purpose of transmitting data via control plane CIoT EPS optimization. A true value of the CP-only connection field may indicate that the RRC connection is fixed to the control plane (e.g., the RRC connection is only used to send data via control plane optimization and cannot be switched to the user plane).

The RRC connection may have both Signaling Radio Bearers (SRBs) and Data Radio Bearers (DRBs). When a PDN connection is referred to as fixed to the control plane, as described herein, this may imply that only RRC/SRB is used on the radio interface, and that RRC/DRB is not used.

In some embodiments, message 3 may have only one spare bit, and thus may multiplex both indicators. For example, only the CP connection value may also indicate CP data. Alternatively, message 3 may rely on a larger UL grant.

In some embodiments, in alternative 2, the RRC connection request message may be used to provide a CP data indication via a new establishment cause. The establishment cause may provide an indication of why the UE104 needs to connect to the network. In some embodiments, the establishment cause may be determined by the NAS procedure for which the RRC connection is being established.

Similar to the RRC connection request message described above, the following messages may be sent from UE104 to RAN 110 on SRB 0; with TM RLC-SAP; and transmitted in a logical channel such as the CCCH. In some embodiments, the RRC connection request message may have an asn.1 structure as shown below.

RRC connection request message

Therefore, CP data and only CP connection values are added as possible values that can be used in the establishment cause.

In alternative 3, a new LCID may be used for message 3. The MAC headers for the downlink shared channel ("DL-SCH"), the uplink shared channel ("UL-SCH"), and the multicast channel ("MCH") are variable in size and consist of the following fields: LCID; l; f; f2 and E.

The LCID field may include an LCID value that identifies a logical channel instance of a corresponding MAC SDU or a type of corresponding MAC control element or padding, as described (below) in tables 1 and 2 for DL-SCH and UL-SCH, respectively. Tables 1 and 2 may be similar to tables 6.2.1-1 and 6.2.1-2 of 3GPP TS 36.321v14.2.0(2017-03), unless otherwise noted.

There may be one LCID field for each MAC SDU, MAC control element, or padding included in the MAC PDU. In addition, one or two additional LCID fields may be included in the MAC PDU when single or double byte padding is required but cannot be achieved by padding at the end of the MAC PDU. In some embodiments, if the UE104 is a category 0UE (e.g., a low cost/low power UE), the UE104 may indicate CCCH using LCID "01011"; if the UE104 is transmitting data using CP EPS CIoT optimization, the UE104 may indicate CCCH using LCID "01100"; and the UE104 may additionally indicate CCCH using LCID "00000". The LCID field size may be 5 bits.

The L field may include a length value to indicate the length of the corresponding MAC SDU or variable size MAC control element in bytes. Each MAC PDU subheader may have an L field except for the last subheader and the subheader corresponding to the fixed size MAC control element. The size of the L field may be indicated by the F field and the F2 field.

The F field may include a format value to indicate the size of the L field. There may be one F field per MAC PDU subheader, except for the last subheader and the subheader corresponding to the fixed size MAC control element, and except that F2 is set to 1. The size of the F field may be 1 bit. If the F field is included, if the size of the MAC SDU or variable-size MAC control element is less than 128 bytes, the value of the F field may be set to 0; otherwise it may be set to 1.

The F2 field may include a format 2 value to indicate the size of the L field. There may be one F2 field per MAC PDU subheader. The F2 field may be 1 bit in size. The value of the F2 field may be set to 1 if the size of the MAC SDU or variable size MAC control element is greater than 32,767 bytes and if the corresponding subheader is not the last subheader, and may be set to 0 otherwise.

The E field may include an extension flag to indicate whether there are more fields in the MAC header. The E field may be set to "1" to indicate another set of at least R/F2/E/LCID fields. The E field may be set to "0" to indicate that the MAC SDU, MAC control element, or padding starts at the next byte.

The R field may include a reserved bit set to "0".

The MAC header and the subheader may be octet aligned.

TABLE 1 LCID values for DL-SCH

For NB-IoT, the following LCID values for DL-SCH only may apply: CCCH, identification of logical channels, UE contention resolution identification, timing advance command, discontinuous reception ("DRX") command, and padding.

TABLE 2 LCID values for UL-SCH

For NB-IoT, the following LCID values for UL-SCH only may apply: CCCH (LCID "00000"), identification of logical channels, cell radio network temporary identifier ("C-RNTI"), short buffer status report ("BSR"), and padding.

In alternative 4, the NAS layer 224 of the UE104 will provide a CP data indication to the AS of the UE104 (e.g., to the RRC 220 of the UE 104) indicating that the NAS message contains data to be sent via the control plane CIoT EPS optimization. The AS of the UE104 may establish the RRC connection by including the new CP data indication IE in message 5 and send message 5 (e.g., RRC connection setup complete, which may be used to confirm successful establishment of the RRC connection). If the S1-AP layer 228 of the AN 108 has received AN S1-AP overload start command from the S1-AP layer 228 of the MME 124 indicating AN overload due to the control plane message, the AN 108 may reject the message 5 with the reason code-control plane data overload and provide a backoff (backoff) timer value to the UE in AN RRC reject message.

In another alternative, the above-mentioned CP data indication has a slightly different definition and refers only to data to be sent via a CP over a CP fixed connection (with the understanding that SCEF PDN connection is always fixed to CP, whereas SGi PDN connection may or may not be fixed) or a non-fixed connection. One possible advantage is that the eNB may let the MME decide to switch to the user plane based on the indication.

An example asn.1 defining this new indication is shown below for reference using RRC connection request and RRC connection setup complete as references; however, as previously mentioned, similar fields may be defined in other messages 3 or 5. Furthermore, LTE RRC messages are used; however, the same new fields, e.g., RRC connection setup complete-NB, may be defined on the equivalent NB-IoT message.

An RRC connection setup complete message may be sent from UE104 to RAN 110 on SRB 1; RLC-SAP with acknowledged mode ("AM"); and transmitted in a logical channel such as a dedicated control channel ("DCCH"). In some embodiments, the RRC connection request message may have an asn.1 structure as shown below.

RRC connection setup complete message

The CP data field may be included (and set to "true") when the UE104 transmits data using control plane CIoT EPS optimization. When the UE104 sends data over the control plane CIoT EPS optimized EPS bearer fixed to the control plane CIoT EPS optimization using control plane CIoT EPS optimization, the CP-only connection field may be included (and set to "true").

It is noted that the above alternatives are not mutually exclusive. Various combinations of alternatives may be used. For example, alternative 3 may include an LCID value that indicates whether the UE104 sends data over the control plane CIoT EPS optimized EPS bearer fixed to the control plane CIoT EPS optimization using control plane CIoT EPS optimization. For another example, the eNB may reject the RRC message 3 message directly when the RRC message 3 message includes a CP-only connection indication (and the MME is overloaded). If the RRC message 3 does not indicate anything, it can be assumed that it is not fixed to the CP. Alternative 4 may then be used, for example RRC message 5 may indicate that it is CP data. Thus, the information is sent in two parts.

In some embodiments, the UE104 may support both control plane and user plane optimization. If the UE104 supports EPS CIoT optimization and has an SGi PDN connection not fixed to the CP (e.g., path 2 of fig. 1), the UE104 can switch from CP to UP if congestion is caused due to control plane data.

As described above in alternative 4, the NAS layer 224 of the UE104 may provide a CP data indication to the RRC layer 220 of the UE104 to indicate that the NAS message contains data to be sent via the control plane CIoT EPS optimization. The RRC layer 220 of the UE104 may then establish the RRC connection and may send a message 5 including the CP data indication IE (e.g., RRC connection setup complete). If AN 108 has received the S1-AP overload start command from MME 124, AN 108 may reject RRC message 5 with reason code-control plane data overload and provide the backoff timer value to the UE in AN RRC reject message. Since the UE104 also supports UP EPS CIoT optimization (or legacy S1-U), the UE104 can decide to establish a new RRC connection for UP by sending a NAS service request in message 5.

Alternatively, to conserve UE battery and reduce load on the AN 108 or MME 124, some embodiments may cause the MME 124 to switch the connection to the user plane if the SGi PDN connection is not fixed to the control plane. These embodiments are described in the message flow of fig. 3.

Fig. 3 illustrates a flow 300 for MME 124 to switch from control plane to user plane due to congestion from control plane data, in accordance with some embodiments.

To establish the RRC connection, the UE104 may send an RRC message 5 at 304. The RRC message 5 may include a NAS control plane service request ("CPSR") message. The CPSR message may be an integrity protected NAS message. The CPSR message may include an EPS bearer ID ("EBI") and encrypted uplink data. The RRC message 5 may also include a CP data indication to indicate that the user data transmission message is transmitted in the CPSR message. The RRC message 5 may also include a CP-only connection to indicate whether the EPS bearer corresponding to the EBI is fixed to the control plane.

At 308, AN 108 can determine whether RRC message 5 includes control plane data for MME 124 that is congested (as previously indicated to AN 108). The AN 108 may then determine whether message 5 sets the CP-only connection to true or false (false). If the CP-only connection is set to true, indicating that the EBI is fixed only to the control plane, and the MME 124 has indicated that the AN 108 is to stop loading of CP data, the AN 108 may send AN RRC reject message to the UE104, and the flow may stop here.

If the CP-only connection is set to false, as in the assumption shown in FIG. 3, the AN 108 may determine that the EBI is not fixed only to the control plane. The AN 108 may then send AN S1-AP initial UE message to the MME 124 at 312. The S1-AP initial UE message may include a CPSR message carrying an EBI.

At 316, if MME 124 is overloaded and based on operator policy that causes it to limit loading from CP data, MME 124 may check whether the EBI received in the S1-AP message is fixed to the control plane. Assuming that the access node 108 will likely reject the RRC message 5 with only the CP connection set to true, the chance of the MME 124 receiving the S1-AP initial UE message carrying the EBI fixed to the control plane may be relatively small when the MME is overloaded.

If the EBI is not fixed to the control plane (which is the most likely case), the MME 124 may decide to switch the connection to the user plane based on operator policy. The MME 124 may also decide to forward the data in the CPSR message via S11-U. Alternatively, the MME 124 may decide to inform the UE104 to retransmit the data over the user plane by including a new indicator in the NAS response/S1-AP message.

If an S11-U interface has not been established between the MME and the S-GW/P-GW120, and the MME 124 decides to establish an S11-U interface for forwarding data over the control plane, the flow 300 may include message exchanges at 320 and 324. Specifically, at 320, MME 124 may send a modify bearer request to S-GW/P-GW120 to modify an existing bearer. Then, at 324, the S-GW/P-GW120 may send a modify bearer response to the MME 124 in response.

In some embodiments, if MME 124 decides to establish an S1-U interface between UE104 and S-GW/P-GW120, the message exchange at 320 and 324 may also be used for UE104 to retransmit data over the user plane connection.

If the MME 124 decides to forward the data in the CPSR over the control plane via the S11-U interface, the MME 124 may send uplink data to the S-GW/P-GW120 at 328.

At 332, flow 300 may include MME 124 deciding to switch to the user plane. At 336, MME 124 may initiate the establishment of DRB and S1-U interfaces by sending an S1-AP initial context setup request ("ICSR") message. The S1-AP ICSR message may include a control plane back-off timer ("BOT") value and an indication to retransmit data over the user plane. The CP BOT value may prevent the UE104 from sending additional uplink data over the control plane connection for a period of time.

The flow 300 may also include, at 340, the AN 108 and the UE104 performing a radio bearer establishment procedure to establish the DRB.

At 344, the AN 108 can send AN RRC downlink ("DL") message. The RRC downlink message may include a control plane backoff timer and an indication to retransmit the data.

Upon receiving the retransmission indication in the RRC DL message, the UE104 may transmit data to the AN 108 over the user plane at 348. The AN 108 may also transmit UL data to the S-GW/P-GW120 over the user plane at 352.

Fig. 4 illustrates a flow 400 of an overload start message for data transmission via a control plane for a CP fixed connection, in accordance with some embodiments.

Flow 400 may include, at 404, MME 124 determining an overload condition at MME 124. An overload condition may be determined when the amount of traffic, including, for example, control plane EPS optimization data, reaches a predetermined threshold. Upon determining the overload condition, the MME 124 may initiate a procedure to limit data transmission via the control plane CIoT EPS optimization. The criteria (e.g., predetermined threshold) for limiting control plane data transmission and the process of doing so may be based on operator policy or configuration.

Upon determining the overload condition, MME 124 may send AN S1-AP overload start message to AN 108 at 408. The S1-AP overload start message may include a control plane CIoT data parameter that informs the AN 108 that the MME 124 is overloaded. In some embodiments, the overload condition determined at 404 and signaled at 408 may indicate that MME 124 is approaching overload, rather than already being overloaded.

The S1-AP overload start message may also include a CP only indication to instruct the AN 108 to perform overload limiting only for CP fixed connections. In the case where the CP-only indication is not included in the S1-AP overload start message, AN 108 may perform overload limiting for all connections. The flow 400 may also include, at 412, the UE104 sending AN RRC message 5 to the AN 108. The RRC message 5 may include a CP data indicator to indicate that the RRC message 5 includes control plane data. The RRC message 5 may also include a CP only connection indicator to indicate that the EPS bearer is fixed to the control plane.

At 416, AN 108 may check to determine whether RRC message 5 is for a congested MME and whether it corresponds to a CP fixed connection. The access node 108 may check to determine whether the RRC message 5 includes an MME identification, e.g., a registered MME parameter, that identifies the MME that previously sent the S1-AP overload start message. For example, if RRC message 5 includes an MME identification corresponding to MME 124, access node 108 may determine, for this embodiment, that RRC message 5 is for a congested MME.

The AN 108 may send a CP data message to the MME 124 if AN RRC message 5 is received while the MME 124 is overloaded, but does not include a CP-only connection indicator. MME 124 may decide to switch the control plane to the user plane as shown above with reference to fig. 3.

At 416, if it is determined that RRC message 5 is received while MME 124 is overloaded and RRC message 5 includes a CP-only connection indicator, at 420, AN 108 may send AN RRC reject message to UE 104. The RRC reject message may include a backoff timer value. The UE104 may start the back-off timer using the back-off timer value received in the RRC connection reject message. Upon expiration of the backoff timer, the UE104 may send an additional message to send data via the control plane.

In some embodiments, access node 108 may be coupled with multiple MMEs. If the access node 108 receives an overload message from the first MME, it can still send CP data messages to the second MME connected to it.

Fig. 5 illustrates an example operational flow/algorithm structure of the UE104 in accordance with some embodiments.

At 504, flow/structure 500 may include generating and transmitting a CP data message. In some embodiments, the CP data message may be generated by the NAS layer 224 of the UE104, providing the NAS message and the CP data indication to the AS of the UE 104. The CP data indication may indicate that the NAS message contains data to be sent via the control plane CIoT EPS optimization. The AS of the UE104 may then generate and send one or more RRC messages (e.g., RRC message 3 or RRC message 5) that carry, for example, a CP data indication or a CP-only connection indication AS described above.

At 508, flow/structure 500 can also include receiving AN RRC message from AN 108. The RRC message may be an RRC DL message as described in fig. 3 or an RRC connection reject message as described in fig. 4. The RRC message may include a CP BOT value. In some embodiments, the RRC message may include a retransmission indicator that instructs the UE104 to retransmit the data previously transmitted in the CP data message.

At 512, flow/structure 500 may also include setting a backoff timer with the CP BOT value received in the RRC message. In some embodiments, the back-off timer may be reset to the new CP-BOT value if the back-off timer is running while the new CP BOT value is running. In other embodiments, the CP BOT value may be added to the remaining time on the backoff timer when a new CP BOT value is received.

At 516, flow/structure 500 may also include generating and transmitting another CP data message. The other CP data message may be generated similarly to the CP data message generated at 504. The another CP data message may be transmitted after the back-off timer expires.

Fig. 6 illustrates AN example operational flow/algorithm structure 600 of the AN 108 according to some embodiments.

At 604, flow/structure 600 may include processing the CPSR message. The CPSR message may include an EBI that identifies the EPS bearer of the UE 104. In some embodiments, the CPSR may be included in an RRC message, e.g., RRC message 3 or RRC message 5. In some embodiments, the CPSR message or the encapsulating RRC message may also include an MME identification corresponding to MME 124.

At 608, flow/structure 600 may also include determining whether an MME (e.g., MME 124) indicated in the CPSR is overloaded. AN 108 may determine that MME 124 is overloaded based on previously receiving AN S1-AP overload start message from MME 124.

At 608, if it is determined that MME 124 is not overloaded, flow/structure 600 may further include forwarding the CPSR message to MME 124 at 612. In some embodiments, the CPSR message may be forwarded to MME 124 in an S1-AP initial UE message.

At 608, if MME 124 is determined to be overloaded, then at 616, flow/structure 600 may further include determining whether the data is to be sent by a bearer that is fixed to the CP-only connection. The AN 108 can determine whether data will be transmitted by a bearer fixed to the CP-only connection by checking the CP-only field in the RRC message transmitting the CPSR message.

At 616, if it is determined that the relevant bearer is not fixed to the CP-only connection, flow/structure 600 may proceed to forward the CPSR message to MME 124 at 612.

If, at 616, it is determined that the associated bearer is fixed to the CP-only connection, then at 620, flow/structure 600 may proceed to send an RRC connection reject message. In some embodiments, the RRC connection reject message may include a CP BOT value that the UE104 may use to start a CP backoff timer.

Fig. 7 illustrates an example operational flow/algorithm structure 700 of the MME 124 in accordance with some embodiments.

At 704, flow/structure 700 can include processing the CPSR message. The CPSR message may include an EBI that identifies the EPS bearer of the UE 104. In some embodiments, the CPSR may be included in the S1-AP initial UE message.

At 708, flow/structure 700 may also include detecting an overload condition in the network. In some embodiments, an overload condition may be detected by comparing the level of a particular type of traffic to a predetermined threshold. For example, in some embodiments, MME 124 may compare the level of CP CIoT EPS optimized traffic to a predetermined threshold configured according to operator policy. The MME 124 may detect an overload condition if the detected traffic exceeds a predetermined threshold.

At 708, if an overload condition is not detected, at 712, flow/structure 700 may proceed to transmit data over the control plane.

At 708, if an overload condition is detected, at 716, flow/structure 700 may proceed to determine whether the EPS bearer identified by the EBI is fixed to the CP-only connection. The MME 124 may determine whether data is to be sent by a bearer fixed to a CP-only connection by checking the CP-only field in the S1-AP initial UE message sending the CPSR message.

If, at 716, it is determined that the EPS bearer is fixed to a CP-only connection, at 720, flow/structure 700 may proceed to reject the message. The message may be rejected by sending a reject message to the AN 108. As described above, this situation may occur infrequently, because the AN 108 may have rejected the RRC message if the AN 108 is fixed to the CP-only connection and the MME 124 is overloaded.

At 716, if it is determined that the EPS bearer is not fixed to a CP-only connection, at 724, the flow/structure may proceed to initiate establishment of an S1-U bearer. This may be the result of MME 124 deciding to switch from the control plane to the user plane. In some embodiments, MME 124 may send AN S1-AP message to AN 108. The S1-AP message may be an S1-AP initial context setup request message, which may include the CP BOT value of the UE in some embodiments.

The embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. FIG. 8 illustrates example components of an electronic device 800 for one embodiment. In embodiments, the electronic device 800 may be, may implement, may be incorporated into, or otherwise be part of the UE104, the AN 108, the MME 124, or some other electronic device.

In some embodiments, electronic device 800 may include application circuitry 802, baseband circuitry 804, radio frequency ("RF") circuitry 806, front-end module ("FEM") circuitry 808, and one or more antennas 810 coupled together at least as shown. In embodiments in which the electronic device 800 is implemented in or by AN (e.g., eNB) or MME, the electronic device 800 may further include network interface circuitry (not shown) for communicating over a wired interface (e.g., X2 interface, S1 interface, etc.).

As used herein, the term "circuitry" may refer to, be part of, or include the following: an application specific integrated circuit ("ASIC"), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with, one or more software or firmware modules. In some embodiments, the circuitry may comprise logic operable, at least in part, in hardware.

The application circuitry 802 may include one or more application processors. For example, the application circuitry 802 may include circuitry such as, but not limited to: one or more single-core or multi-core processors 802 a. The processor(s) 802a can include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). Processor 802a can be coupled to and/or can include a computer-readable medium 802b (also referred to as "CRM 802b," "memory 802b," "storage 802b," or "memory/storage 802 b"), and can be configured to execute instructions stored in CRM 802b to enable various applications and/or operating systems to run on the system.

Baseband circuitry 804 may include circuitry such as, but not limited to: one or more single-core or multi-core processors. Baseband circuitry 804 may include one or more baseband processors and/or control logic to process baseband signals received from the receive signal path of RF circuitry 806 and to generate baseband signals for the transmit signal path of RF circuitry 806. Baseband processing circuits 804 may interface with the application circuits 802 to generate and process baseband signals and control the operation of the RF circuits 806. For example, in some embodiments, the baseband circuitry 804 may include a second generation ("2G") baseband processor 804a, a third generation ("3G") baseband processor 804b, a fourth generation ("4G") baseband processor 804c, a fifth generation ("5G") baseband processor 804h, and/or other baseband processor(s) 804d for other existing generations, generations in development or to be developed in the future (e.g., 6G, etc.). The baseband circuitry 804 (e.g., one or more of the baseband processors 804a-d, h) may handle various radio control functions that support communication with one or more radio networks via the RF circuitry 806. The radio control functions may include, but are not limited to: signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, the modulation/demodulation circuitry of baseband circuitry 804 may include Fast Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, the encoding/decoding circuitry of baseband circuitry 804 may include convolution, tail-biting convolution, turbo, Viterbi (Viterbi), and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

In some embodiments, the baseband circuitry 804 may include elements of a protocol stack, e.g., elements of an E-UTRAN protocol, including, e.g., PHY, MAC, RLC, PDCP, and/or RRC elements. A Central Processing Unit (CPU)804e of the baseband circuitry 804 may be configured to run elements of a protocol stack for signaling of the PHY, MAC, RLC, PDCP, and/or RRC layers. In some embodiments, the baseband circuitry 804 may include one or more audio Digital Signal Processors (DSPs) 804 f. The audio DSP(s) 804f may include elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments. The baseband circuitry 804 may also include a computer-readable medium 804g (also referred to as "CRM 804g," "memory 804g," "storage 804g," or "memory/storage 804 g"). CRM 804g may be used to load and store data and/or instructions for operations performed by the processor of baseband circuitry 804. CRM 804g for one embodiment may include any combination of suitable volatile memory and/or non-volatile memory. The CRM 804g may include any combination of various levels of memory/storage, including but not limited to Read Only Memory (ROM) with embedded software instructions (e.g., firmware), random access memory (e.g., Dynamic Random Access Memory (DRAM)), cache, buffers, and the like. The CRM 804g may be shared among various processors or dedicated to a particular processor. In some embodiments, the components of baseband circuitry 804 may be combined in a single chip or a single chipset, or disposed on the same circuit board, as appropriate. In some embodiments, some or all of the constituent components of the baseband circuitry 804 and the application circuitry 802 may be implemented together, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 804 may provide communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 804 may support communication with E-UTRAN and/or other wireless metropolitan area networks ("WMANs"), wireless local area networks ("WLANs"), wireless personal area networks ("WPANs"). Embodiments in which the baseband circuitry 804 is configured to support radio communications of multiple wireless protocols may be referred to as multi-mode baseband circuitry.

The RF circuitry 806 may support communication with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 806 may include switches, filters, amplifiers, and the like to facilitate communication with the wireless network. RF circuitry 806 may include a receive signal path that may include circuitry to down-convert RF signals received from FEM circuitry 808 and provide baseband signals to baseband circuitry 804. RF circuitry 806 may also include a transmit signal path that may include circuitry to up-convert baseband signals provided by baseband circuitry 804 and provide an RF output signal to FEM circuitry 808 for transmission.

In some embodiments, RF circuitry 806 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 806 may include a mixer circuit 806a, an amplifier circuit 806b, and a filter circuit 806 c. The transmit signal path of the RF circuitry 806 may include a filter circuit 806c and a mixer circuit 806 a. The RF circuitry 806 may also include synthesizer circuitry 806d for synthesizing frequencies for use by the mixer circuitry 806a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 806a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 808 based on the synthesized frequency provided by the synthesizer circuitry 806 d. The amplifier circuit 806b may be configured to amplify the downconverted signal, and the filter circuit 806c may be a Low Pass Filter (LPF) or a Band Pass Filter (BPF) configured to remove unwanted signals from the downconverted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuitry 804 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, but this is not required. In some embodiments, mixer circuit 806a of the receive signal path may comprise a passive mixer, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 806a of the transmit signal path may be configured to up-convert the input baseband signal based on a synthesis frequency provided by the synthesizer circuitry 806d to generate an RF output signal for the FEM circuitry 808. The baseband signal may be provided by baseband circuitry 804 and may be filtered by filter circuitry 806 c. Filter circuit 806c may include a Low Pass Filter (LPF), although the scope of the embodiments is not limited in this respect.

In some embodiments, mixer circuit 806a of the receive signal path and mixer circuit 806a of the transmit signal path may include two or more mixers and may be arranged for quadrature down-conversion and/or up-conversion, respectively. In some embodiments, the mixer circuitry 806a of the receive signal path and the mixer circuitry 806a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuit 806a of the receive signal path and the mixer circuit 806a of the transmit signal path may be arranged for direct down-conversion and/or direct up-conversion, respectively. In some embodiments, mixer circuit 806a of the receive signal path and mixer circuit 806a of the transmit signal path may be configured for superheterodyne operation.

In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, the RF circuitry 806 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and the baseband circuitry 804 may include a digital baseband interface to communicate with the RF circuitry 806.

In some dual-mode embodiments, separate radio IC circuitry may be provided to process signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, synthesizer circuit 806d may be a fractional-N synthesizer or a fractional-N/N +1 synthesizer, although the scope of embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuit 806d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase locked loop with a frequency divider. The synthesizer circuit 806d may be configured to synthesize an output frequency for use by the mixer circuit 806a of the RF circuit 806 based on the frequency input and the divider control input. In some embodiments, synthesizer circuit 806d may be a fractional-N/N +1 synthesizer.

In some embodiments, the frequency input may be provided by a Voltage Controlled Oscillator (VCO), but this is not required. The divider control input may be provided by the baseband circuitry 804 or the application circuitry 802 depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a look-up table based on the channel indicated by the application circuitry 802.

Synthesizer circuit 806d of RF circuit 806 may include a frequency divider, a Delay Locked Loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the divider may be a dual-mode divider (DMD) and the phase accumulator may be a Digital Phase Accumulator (DPA). In some embodiments, the DMD may be configured to divide an input signal by N or N +1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, a DLL may include a set of cascaded, tunable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these embodiments, the delay elements may be configured to decompose the VCO period into at most Nd equal phase groups, where Nd is the number of delay elements in the delay line. In this manner, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuit 806d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used with a quadrature generator and divider circuit to generate a plurality of signals having a plurality of mutually different phases at the carrier frequency. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuitry 806 may include an IQ/polarity converter.

FEM circuitry 808 may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas 810, amplify the received signals, and provide amplified versions of the received signals to RF circuitry 806 for further processing. FEM circuitry 808 may also include a transmit signal path that may include circuitry configured to amplify signals provided by RF circuitry 806 for transmission by one or more of the one or more antennas 810. In some embodiments, FEM circuitry 808 may include TX/RX switches to switch between transmit mode and receive mode operation. FEM circuitry 808 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a Low Noise Amplifier (LNA) to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., to RF circuitry 806). The transmit signal path of FEM circuitry 808 may include a Power Amplifier (PA) to amplify an input RF signal (e.g., provided by RF circuitry 806) and one or more filters to generate an RF signal for subsequent transmission (e.g., by one or more of the one or more antennas 810).

In some embodiments, electronic device 800 may include additional elements, such as a display, a camera, one or more sensors, and/or interface circuitry (e.g., an input/output (I/O) interface or bus) (not shown). In embodiments where the electronic device is implemented in or by an eNB, the electronic device 800 may include network interface circuitry. The network interface circuits may be one or more computer hardware components that connect the electronic device 800 via a wired connection to one or more network elements, such as one or more servers within a core network or one or more other enbs. To this end, the network interface circuitry may include one or more special-purpose processors and/or Field Programmable Gate Arrays (FPGAs) to communicate using one or more network communication protocols, such as X2 Application Protocol (AP), S1AP, Stream Control Transmission Protocol (SCTP), ethernet, point-to-point (PPP), Fiber Distributed Data Interface (FDDI), and/or any other suitable network communication protocol.

In some embodiments, electronic device 800 may be configured to perform one or more processes, techniques, and/or methods, or portions thereof, as described herein. For example, electronic device 800 may implement the flows/structures illustrated and described above with respect to fig. 3-7.

Fig. 9 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments. In particular, fig. 9 shows a graphical representation of hardware resources 900, including one or more processors (or processor cores) 910, one or more memory/storage devices 920, and one or more communication resources 930, each of which may be communicatively coupled via a bus 940. For embodiments utilizing node virtualization (e.g., network function virtualization ("NFV")), hypervisor 902 may be executed to provide an execution environment for one or more network slices/subslices to utilize hardware resources 900.

Processor 910, such as a CPU, a reduced instruction set computing ("RISC") processor, a complex instruction set computing ("CISC") processor, a graphics processing unit ("GPU"), a digital signal processor ("DSP") (such as a baseband processor, an application specific integrated circuit ("ASIC"), a radio frequency integrated circuit ("RFIC"), another processor, or any suitable combination thereof) may include, for example, processor 912 and processor 914.

Memory/storage 920 may include a main memory, a disk storage, or any suitable combination thereof. The memory/storage 920 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory ("DRAM"), static random access memory ("SRAM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), flash memory, solid state storage, and the like.

The communication resources 930 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 904 or one or more databases 906 via the network 908. For example, communication resources 930 may include a wired communication component (e.g., for coupling via a universal serial bus ("USB"), a cellular communication component, a near field communication ("NFC") component, a wireless communication component, and/or a wireless communication component,

The components (e.g.,

low power consumption),

Components and other communication components.

The instructions 950 may include software, a program, an application, an applet, an app, or other executable code for causing at least any one of the processors 910 to perform any one or more of the methodologies discussed herein.

In embodiments where the hardware resources 900 are incorporated into the UE104, the instructions 950 may cause the processor 910 to perform the operational flow/algorithm structure 500, or other operations of the UE such as described in the flows of fig. 3-4.

In embodiments where hardware resources 900 are incorporated into AN 108, instructions 950 may cause processor 910 to perform operational flow/algorithm structure 600, or other operations of AN such as described in the flows of fig. 3-4.

In embodiments where hardware resources 900 are incorporated into MME 124, instructions 950 may cause processor 910 to perform operational flow/algorithm structure 700, or other operations of the MME such as described in the flows of fig. 3-4.

The instructions 950 may reside, completely or partially, within at least one of the processors 910 (e.g., within a cache memory of the processor), the memory/storage 920, or any suitable combination thereof. Further, any portion of instructions 950 may be communicated to hardware resource 900 from any combination of peripherals 904 or database 906. Thus, the processor 910, memory/storage 920, peripherals 904, and memory of database 906 are examples of computer-readable and machine-readable media.

The resources described in fig. 9 may also be referred to as circuitry. For example, the communication resources 930 may also be referred to as communication circuitry 930.

Some non-limiting examples are provided below.

Example 1 includes one or more computer-readable media having instructions that, when executed, cause a mobility management entity ("MME") to: processing a control plane service request ("CPSR") message carrying an evolved packet service bearer identity ("EBI") for identifying an evolved packet service ("EPS") bearer of a user equipment; detecting an overload condition in the network; determining that an EPS bearer is not fixed to a Control Plane (CP) -only connection; and initiating establishment of an S1-U bearer for the user equipment based on the detection of the overload condition and the determination that the EPS bearer is not fixed to the CP-only connection.

Example 2 includes the one or more computer-readable media of example 1 or some other example herein, wherein the instructions, when executed, further cause the MME to: the uplink data is forwarded through a user plane connection with the gateway.

Example 3 includes the one or more computer-readable media of example 1 or some other example herein, wherein the instructions, when executed, further cause the MME to: a backoff timer value is sent to a user equipment ("UE") within a non-access stratum ("NAS") message to prevent the UE from sending additional uplink data over the control plane connection.

Example 4 includes the one or more computer-readable media of example 3 or some other example herein, wherein the instructions, when executed, further cause the MME to: the backoff timer value is sent in an S1-access point ("AP") initial context setup request message.

Example 5 includes the one or more computer-readable media of example 4 or some other example herein, wherein the instructions, when executed, further cause the MME to: an indication for instructing the UE to retransmit data of the CPSR message through the user plane connection is transmitted in the S1-AP initial context setup request message.

Example 6 includes the one or more computer-readable media of any one of examples 1-5 or some other example herein, wherein the instructions, when executed, further cause the MME to: sending a modify bearer request to the serving/packet gateway to modify an existing bearer for transmission of uplink data from the user equipment; and receives a modified bearer response from the serving/packet gateway.

Example 7 includes the one or more computer-readable media of example 6 or some other example herein, wherein the modify bearer request is to modify an existing bearer for uplink data transmission over the S11-U interface, and the instructions, when executed, further cause the MME to: the uplink data is transmitted through the S11-U interface.

Example 8 includes the one or more computer-readable media of example 6 or some other example herein, wherein the modify bearer request is to modify an existing bearer for uplink data transmission over the S1-U interface, and the instructions, when executed, further cause the MME to: a message is sent instructing the user equipment to send uplink data over the S1-U interface.

Example 9 includes the one or more computer-readable media of any one of examples 1-8 or some other example herein, wherein the instructions, when executed, further cause the MME to: comparing an amount of traffic including control plane evolved packet system ("EPS") optimization data to a predetermined threshold; detecting an overload condition; and sending S1-AP overload start message to the access node based on said detection of an overload condition.

Example 10 includes one or more computer-readable media having instructions that, when executed, cause an evolved node B ("eNB") to: receiving a first message from a user equipment ("UE"), the first message including data to be sent over a control plane connection via a mobility management entity ("MME"); determining whether the MME is overloaded; determining, based on the first message, whether data is to be sent by a bearer that is fixed to the control plane only connection; forwarding the first message to the MME if it is determined that the data is to be sent by a bearer that is fixed to the control plane only connection; and transmitting a radio resource control ("RRC") connection reject message to the UE if it is determined that the data is to be transmitted by a bearer that is not fixed to the control plane-only connection.

Example 11 includes the one or more computer-readable media of example 10 or some other example herein, wherein the instructions, when executed, further cause the eNB to: determining that data is to be sent by a bearer that is fixed to the control plane only connection; and sending an RRC connection reject message to the UE carrying the backoff timer value to prevent the UE from sending further uplink data over the control plane connection.

Example 12 includes the one or more computer-readable media of example 10 or some other example herein, wherein the instructions, when executed, further cause the eNB to: determining that data is to be sent by a bearer that is not fixed to the control plane only connection; and forwards the first message in an S1-AP initial UE message.

Example 13 includes the one or more computer-readable media of example 12 or some other example herein, wherein the instructions, when executed, further cause the eNB to: receiving an S1-AP initial context setup request ("ICSR") message, the S1-AP initial context setup request message including an indication that the UE is to retransmit data over the user plane connection; and sending an RRC download message with the indication to the UE.

Example 14 includes the one or more computer-readable media of example 13 or some other example herein, wherein the S1-AP ICSR message and the RRC download message further include a backoff timer value to prevent the UE from transmitting other uplink data over the control plane connection.

Example 15 includes the one or more computer-readable media of examples 13 or 14 or some other example herein, wherein the instructions, when executed, further cause the eNB to: a second message is received from the UE, the second message including data to be sent over the user plane connection.

Example 16 includes one or more computer-readable media having instructions that, when executed, cause a user equipment ("UE") to: generating and transmitting a first control plane ("CP") data message to transmit data over a control plane connection; receiving a radio resource control ("RRC") message having a backoff timer value; setting a CP backoff timer based on a backoff timer value; and generating and transmitting a second CP data message when the CP backoff timer expires.

Example 17 includes the one or more computer-readable media of example 16 or some other example herein, wherein the first CP data message comprises an RRC message.

Example 18 includes the one or more computer-readable media of example 17 or some other example herein, wherein the RRC message is an RRC connection request message or an RRC connection setup complete message.

Example 19 includes the one or more computer-readable media of example 16 or some other example herein, wherein the first CP data message comprises a control plane service request message.

Example 20 includes the one or more computer-readable media of any one of examples 16-18 or some other example herein, wherein the first CP data message includes a CP data indicator to indicate that the first CP data message is for establishing a connection for transmitting data via the control plane, or includes a CP only connection indicator to indicate that a connection to be established for transmitting data via the control plane is fixed to the control plane.

Example 21 includes processing circuitry to be implemented within a mobility management entity ("MME"), the processing circuitry configured to cause the MME to: processing a control plane service request ("CPSR") message carrying an evolved packet service bearer identity ("EBI") for identifying an evolved packet service ("EPS") bearer of a user equipment; detecting an overload condition in the network; determining that an EPS bearer is not fixed to a Control Plane (CP) -only connection; and initiating establishment of an S1-U bearer for the user equipment based on the detection of the overload condition and the determination that the EPS bearer is not fixed to the CP-only connection.

Example 22 includes the processing circuitry of example 21 or some other example herein, wherein the instructions, when executed, further cause the MME to: the uplink data is forwarded through a user plane connection with the gateway.

Example 23 includes the processing circuitry of example 21 or some other example herein, wherein the instructions, when executed, further cause the MME to: a backoff timer value is sent to a user equipment ("UE") within a non-access stratum ("NAS") message to prevent the UE from sending additional uplink data over the control plane connection.

Example 24 includes the processing circuitry of example 23 or some other example herein, wherein the processing circuitry is further configured to cause the MME to: the backoff timer value is sent in an S1-access point ("AP") initial context setup request message.

Example 25 includes the processing circuitry of example 24 or some other example herein, wherein the processing circuitry is further configured to cause the MME to: an indication for instructing the UE to retransmit data of the CPSR message through the user plane connection is transmitted in the S1-AP initial context setup request message.

Example 26 includes the processing circuitry of any one of examples 21-25 or some other example herein, wherein the processing circuitry is further configured to cause the MME to: sending a modify bearer request to the serving/packet gateway to modify an existing bearer for transmission of uplink data from the user equipment; and receives a modified bearer response from the serving/packet gateway.

Example 27 includes the processing circuitry of example 26 or some other example herein, wherein the modify bearer request is to modify an existing bearer for uplink data transmission over the S11-U interface, and the processing circuitry is further configured to cause the MME to: the uplink data is transmitted through the S11-U interface.

Example 28 includes the processing circuitry of example 26 or 27 or some other example herein, wherein the modify bearer request is to modify an existing bearer for uplink data transmission over the S1-U interface, and the processing circuitry is further configured to cause the MME to: a message is sent instructing the user equipment to send uplink data over the S1-U interface.

Example 29 includes the processing circuitry of any one of examples 21-28 or some other example herein, wherein the processing circuitry is further configured to cause the MME to: comparing an amount of traffic including control plane evolved packet system ("EPS") optimization data to a predetermined threshold; detecting an overload condition; and sending S1-AP overload start message to the access node based on said detection of an overload condition.

Example 30 includes processing circuitry to be implemented in an evolved node B ("eNB"), the processing circuitry configured to cause the eNB to: processing a first message from a user equipment ("UE"), the first message including data to be sent over a control plane connection via a mobility management entity ("MME"); determining whether the MME is overloaded; determining, based on the first message, whether data is to be sent by a bearer that is fixed to the control plane only connection; forwarding the first message to the MME if it is determined that the data is to be sent by a bearer that is fixed to the control plane only connection; and transmitting a radio resource control ("RRC") connection reject message to the UE if it is determined that the data is to be transmitted by a bearer that is not fixed to the control plane-only connection.

Example 31 includes the processing circuitry of example 30 or some other example herein, wherein the processing circuitry is further configured to cause the eNB to: determining that data is to be sent by a bearer that is fixed to the control plane only connection; and sending an RRC connection reject message to the UE carrying the backoff timer value to prevent the UE from sending other uplink data over the control plane connection.

Example 32 includes the processing circuitry of example 30 or some other example herein, wherein the processing circuitry is further configured to cause the eNB to: determining that data is to be sent by a bearer that is not fixed to the control plane only connection; and forwards the first message in an S1-AP initial UE message.

Example 33 includes the processing circuitry of example 32 or some other example herein, wherein the processing circuitry is further configured to cause the eNB to: receiving an S1-AP initial context setup request ("ICSR") message, the S1-AP initial context setup request message including an indication that the UE is to retransmit data over the user plane connection; and sending an RRC download message carrying the indication to the UE.

Example 34 includes the processing circuitry of example 33 or some other example herein, wherein the S1-AP ICSR message and the RRC download message further include a backoff timer value to prevent the UE from transmitting other uplink data over the control plane connection.

Example 35 includes the processing circuitry of example 33 or 34 or some other example herein, wherein the processing circuitry is further configured to cause the eNB to: a second message is received from the UE, the second message including data to be sent over the user plane connection.

Example 36 includes processing circuitry to be implemented in a user equipment ("UE") configured to cause the UE to: generating and transmitting a first control plane ("CP") data message to transmit data over a control plane connection; receiving a radio resource control ("RRC") message having a backoff timer value; setting a CP backoff timer based on a backoff timer value; and generating and transmitting a second CP data message when the CP backoff timer expires.

Example 37 includes the processing circuitry of example 36 or some other example herein, wherein the first CP data message comprises an RRC message.

Example 38 includes the processing circuitry of example 37 or some other example herein, wherein the RRC message is an RRC connection request message or an RRC connection setup complete message.

Example 39 includes the processing circuitry of any one of examples 36-38 or some other example herein, wherein the first CP data message comprises a control plane service request message.

Example 40 includes the processing circuitry of any one of examples 36-39 or some other example herein, wherein the first CP data message includes a CP data indicator to indicate that the first CP data message is for establishing a connection for transmitting data via the control plane, or includes a CP-only connection indicator to indicate that a connection to be established for transmitting data via the control plane is fixed to the control plane.

Example 41 includes a method of operation performed by a mobility management entity ("MME"), the method comprising: processing a control plane service request ("CPSR") message carrying an evolved packet service bearer identity ("EBI") for identifying an evolved packet service ("EPS") bearer of a user equipment; detecting an overload condition in the network; determining that the EPS bearer corresponds to a PDN connection that is not set to a Control Plane (CP) only; and initiating establishment of an S1-U bearer for the user equipment based on the detection of the overload condition and the determination that the EPS bearer corresponds to a PDN connection that is not set to CP only.

Example 42 includes the method of example 41 or some other example herein, wherein the method further comprises: the uplink data is forwarded through a user plane connection with the gateway.

Example 43 includes the method of example 41 or some other example herein, wherein the method further comprises: a backoff timer value is sent to a user equipment ("UE") within a non-access stratum ("NAS") message to prevent the UE from sending additional uplink data over the control plane connection.

Example 44 includes the method of example 43 or some other example herein, wherein the method further comprises: the backoff timer value is sent in an S1-access point ("AP") initial context setup request message.

Example 45 includes the method of example 44 or some other example herein, wherein the method further comprises: an indication for instructing the UE to retransmit data of the CPSR message through the user plane connection is transmitted in the S1-AP initial context setup request message.

Example 46 includes the method of any one of examples 41-45 or some other example herein, wherein the method further comprises: sending a modify bearer request to the serving/packet gateway to modify an existing bearer for transmission of uplink data from the user equipment; and receives a modified bearer response from the serving/packet gateway.

Example 47 includes the method of example 46 or some other example herein, wherein the modify bearer request is to modify an existing bearer for uplink data transmission over the S11-U interface, and the method further comprises: the uplink data is sent over the S11-U interface.

Example 48 includes the method of example 46 or some other example herein, wherein the modify bearer request is to modify an existing bearer for uplink data transmission over the S1-U interface, and the method further comprises: a message is sent instructing the user equipment to send uplink data over the S1-U interface.

Example 49 includes the method of any one of examples 41-48 or some other example herein, wherein the method further comprises: comparing an amount of traffic including control plane evolved packet system ("EPS") optimization data to a predetermined threshold; detecting an overload condition; and sending S1-AP overload start message to the access node based on said detection of an overload condition.

Example 50 includes a method performed by an evolved node B ("eNB"), the method comprising: receiving a first message from a user equipment ("UE"), the first message including data to be sent over a control plane connection via a mobility management entity ("MME"); determining whether the MME is overloaded; determining whether data is to be sent by a bearer fixed to the control plane only connection based on the first message; forwarding the first message to the MME if it is determined that the data is to be sent by a bearer that is fixed to the control plane only connection; and transmitting a radio resource control ("RRC") connection reject message to the UE if it is determined that the data is to be transmitted by a bearer that is not fixed to the control plane-only connection.

Example 51 includes the method of example 50 or some other example herein, wherein the method further comprises: determining that data is to be sent by a bearer that is fixed to the control plane only connection; and sending an RRC connection reject message to the UE carrying the backoff timer value to prevent the UE from sending other uplink data over the control plane connection.

Example 52 includes the method of example 50 or some other example herein, wherein the method further comprises: determining that data is to be sent by a bearer that is not fixed to the control plane only connection; and forwards the first message in an S1-AP initial UE message.

Example 53 includes the method of example 52 or some other example herein, wherein the method further comprises: receiving an S1-AP initial context setup request ("ICSR") message, the S1-AP initial context setup request message including an indication that the UE is to retransmit data over the user plane connection; and sending an RRC download message with the indication to the UE.

Example 54 includes the method of example 53 or some other example herein, wherein the S1-AP ICSR message and the RRC download message further include a backoff timer value to prevent the UE from transmitting other uplink data over the control plane connection.

Example 55 includes the method of example 53 or 54 or some other example herein, wherein the method further comprises: a second message is received from the UE, the second message including data to be sent over the user plane connection.

Example 56 includes a method performed by a user equipment ("UE"), the method comprising: generating and transmitting a first control plane ("CP") data message to transmit data over a control plane connection; receiving a radio resource control ("RRC") message having a backoff timer value; setting a CP backoff timer based on a backoff timer value; and generating and transmitting a second CP data message when the CP backoff timer expires.

Example 57 includes the method of example 56 or some other example herein, wherein the first CP data message comprises an RRC message.

Example 58 includes the method of example 57 or some other example herein, wherein the RRC message is an RRC connection request message or an RRC connection setup complete message.

Example 59 includes the method of example 56 or some other example herein, wherein the first CP data message comprises a control plane service request message.

Example 60 includes the method of any one of examples 56-58 or some other example herein, wherein the first CP data message includes a CP data indicator to indicate that the first CP data message is for establishing a connection for transmitting data via the control plane, or includes a CP-only connection indicator to indicate that a connection to be established for transmitting data via the control plane is fixed to the control plane.

Example 61 includes an apparatus comprising: apparatus for performing any one of the methods of examples 41-60.

Example 62 includes a mobility management entity having: processing circuitry to perform any one of the methods of examples 41-49; and communication circuitry, coupled with the processing circuitry, to transmit messages to or receive messages from a user equipment ("UE") or an evolved node B ("eNB").

Example 63 includes an evolved node b (enb) having: processing circuitry to perform any one of the methods of examples 50-55; and communication circuitry, coupled with the processing circuitry, to transmit messages to or receive messages from a mobility management entity ("MME") or user equipment ("UE").

Example 64 includes a user equipment ("UE") having: processing circuitry to perform any one of the methods of examples 56-60; and communication circuitry, coupled with the processing circuitry, to transmit messages to or receive messages from an evolved node B ("eNB") or a mobility management entity ("MME").

Example 65 includes a radio resource control ("RRC") message, comprising: a Control Plane (CP) data field having a first indicator to indicate whether a user equipment is transmitting data using control plane cellular Internet of things evolved packet System (CIoT EPS) optimization; or a CP-only connection field with a second indicator for indicating whether the user equipment is transmitting data over an evolved packet system bearer fixed to the control plane CIoT EPS optimization using the control plane CIoT EPS optimization.

Example 66 includes the RRC message of example 65, wherein the RRC message is an RRC connection request message or an RRC connection setup complete message.

The description of the illustrated implementations herein, including what is described in the abstract, is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. While specific implementations and examples are described herein for illustrative purposes, various alternative or equivalent embodiments or implementations calculated to achieve the same purposes may be calculated from the above detailed description without departing from the scope of the disclosure, as will be recognized by those skilled in the relevant art.

Example 67 includes processing circuitry to be implemented within a mobility management entity ("MME"), the processing circuitry configured to cause the MME to: processing a control plane service request ("CPSR") message carrying an evolved packet service bearer identity ("EBI") for identifying an evolved packet service ("EPS") bearer of a user equipment; detecting an overload condition in the network; and sending a backoff timer value to a user equipment ("UE") within a non-access stratum ("NAS") message to prevent the UE from sending additional uplink data over the control plane connection.

Example 68 may include the processing circuitry of example 67 or some other example, wherein the instructions, when executed, further cause the MME to: the uplink data is forwarded through a user plane connection with the gateway.

Example 69 may include the processing circuitry of example 67 or some other example, wherein the instructions, when executed, further cause the MME to: determining that the EPS bearer corresponds to a PDN connection that is not set to a Control Plane (CP) only; and initiating establishment of an S1-U bearer for the user equipment based on the detection of the overload condition and determining that the EPS bearer corresponds to a PDN connection that is not set to CP only.

Example 70 may include the processing circuitry of example 67, wherein the processing circuitry is further configured to cause the MME to: the backoff timer value is sent in an S1-access point ("AP") initial context setup request message.

Example 71 may include the processing circuitry of example 70, wherein the processing circuitry is further configured to cause the MME to: an indication for the UE to retransmit data of the CPSR message through the user plane connection is transmitted in the S1-AP initial context setup request message.

Claims (23)

1. One or more computer-readable media having instructions stored thereon that, when executed by one or more processors, cause a Mobility Management Entity (MME) to:

processing a control plane service request CPSR message carrying an evolved packet service bearer identifier (EBI), wherein the EBI is used for identifying an EPS bearer of user equipment;

detecting an overload condition in the network;

determining that the EPS bearer is not fixed to a Control Plane (CP) only connection; and

initiating establishment of an S1-U bearer for the user equipment based on the detection of the overload condition and the determination that the EPS bearer is not anchored to the CP-only connection.

2. The one or more computer-readable media of claim 1, wherein the instructions, when executed, further cause the MME to:

the uplink data is forwarded through a user plane connection with the gateway.

3. The one or more computer-readable media of claim 1, wherein the instructions, when executed, further cause the MME to:

sending a backoff timer value to a user equipment, UE, within a non-access stratum, NAS, message to prevent the UE from sending additional uplink data over a control plane connection.

4. The one or more computer-readable media of claim 3, wherein the instructions, when executed, further cause the MME to:

the back-off timer value is sent in the S1-access point AP initial context setup request message.

5. The one or more computer-readable media of claim 4, wherein the instructions, when executed, further cause the MME to:

transmitting an indication in the S1-AP initial context setup request message, the indication for instructing the UE to retransmit data of the CPSR message through a user plane connection.

6. The one or more computer-readable media of any of claims 1-5, wherein the instructions, when executed, further cause the MME to:

sending a modify bearer request to a serving/packet gateway to modify an existing bearer for transmission of uplink data from the user equipment; and is

Receiving a modified bearer response from the serving/packet gateway.

7. The one or more computer-readable media of claim 6, wherein the modify bearer request is to modify an existing bearer for uplink data transmission over an S11-U interface, and the instructions, when executed, further cause the MME to:

transmitting the uplink data through the S11-U interface.

8. The one or more computer-readable media of claim 6, wherein the modify bearer request is to modify an existing bearer for uplink data transmission over an S1-U interface, and the instructions, when executed, further cause the MME to:

sending a message to instruct the user equipment to send the uplink data over the S1-U interface.

9. The one or more computer-readable media of any of claims 1-5, wherein the instructions, when executed, further cause the MME to, when determining that the EPS bearer is fixed to a CP-only connection:

comparing the amount of traffic comprising control plane evolved packet system, EPS, optimization data with a predetermined threshold;

detecting the overload condition when the amount of traffic reaches the predetermined threshold; and is

Sending S1-AP overload start message to an access node to initiate one or more data transmission restrictions with respect to the control plane based on the detection of the overload condition.

10. An evolved node B, eNB, comprising:

processing circuit, and

a memory having instructions stored thereon that, when executed by the processing circuitry, cause the eNB to:

processing a first message from a user equipment, UE, the first message comprising data to be sent over a control plane connection via a mobility management entity, MME;

determining whether the MME is overloaded;

determining, based on the first message, whether the data is to be sent by a bearer that is fixed to a control plane only connection;

forwarding the first message to the MME if it is determined that the data is to be sent by a bearer that is not fixed to a control plane only connection;

sending a radio resource control, RRC, connection reject message to the UE carrying a backoff timer value to prevent the UE from sending additional uplink data over the control plane connection if it is determined that the data is to be sent by a bearer fixed to only the control plane connection.

11. The eNB of claim 10, wherein the instructions, when executed by the processing circuitry, further cause the eNB to:

determining that the data is to be sent by a bearer that is not secured to the control plane only connection; and is

The first message is forwarded in an S1-AP initial UE message.

12. The eNB of claim 11, wherein the instructions, when executed by the processing circuitry, further cause the eNB to:

receiving an S1-AP Initial Context Setup Request (ICSR) message, the S1-AP initial context setup request message including an indication that the UE is to retransmit data over a user plane connection; and is

Sending an RRC download message with the indication to the UE.

13. The eNB of claim 12, wherein the S1-AP ICSR message and the RRC download message further include a back-off timer value to prevent the UE from transmitting additional uplink data over the control plane connection.

14. The eNB of claim 12 or 13, wherein the instructions, when executed by the processing circuitry, further cause the eNB to:

receiving a second message from the UE, the second message including data to be sent over a user plane connection.

15. One or more computer-readable media having instructions stored thereon that, when executed by one or more processors, cause a user equipment, UE, to:

generating and transmitting a first control plane CP data message to transmit data through a control plane connection;

receiving a radio resource control, RRC, reject message having a backoff timer value in response to the first CP data message when the network is overloaded;

setting a CP backoff timer based on the backoff timer value in response to the RRC reject message; and

generating and transmitting a second CP data message upon expiration of the CP backoff timer.

16. The one or more computer-readable media of claim 15, wherein the first CP data message comprises an RRC message.

17. The one or more computer-readable media of claim 16, wherein the RRC message is an RRC connection request message or an RRC connection setup complete message.

18. The one or more computer-readable media of claim 15, wherein the first CP data message comprises a control plane service request message.

19. The one or more computer-readable media of any of claims 15-17, wherein the first CP data message includes a CP data indicator to indicate that the first CP data message is for establishing a connection for transmitting data via a control plane or includes a CP only connection indicator to indicate that a connection to be established for transmitting data via the control plane is fixed to the control plane.

20. A mobility management entity, MME, comprising:

processing circuit, and

a memory having instructions stored thereon that, when executed by the processing circuitry, cause the MME to:

processing a control plane service request CPSR message carrying an evolved packet service bearer identifier (EBI), wherein the EBI is used for identifying an EPS bearer of user equipment;

determining that the EPS bearer corresponds to a PDN connection that is not set to a control plane CP only;

detecting an overload condition in the network;

initiating establishment of an S1-U bearer for the user equipment based on the detection of the overload condition and the determination that the EPS bearer corresponds to the PDN connection that is not set to CP-only; and

when the overload condition is detected, a backoff timer value is sent to the user equipment, UE, within an S1-AP initial context setup request, ICSR, message to prevent the UE from sending further uplink data over the control plane connection.

21. The MME of claim 20, wherein the instructions, when executed by the processing circuitry, further cause the MME to:

the uplink data is forwarded through a user plane connection with the gateway.

22. The MME of claim 20, wherein the instructions, when executed by the processing circuitry, further cause the MME to:

the back-off timer value is sent in the S1-access point AP initial context setup request message.

23. The MME of claim 22, wherein the instructions, when executed by the processing circuitry, further cause the MME to:

transmitting an indication in the S1-AP initial context setup request message, the indication for instructing the UE to retransmit data of the CPSR message through a user plane connection.

Images