WO2018045302A1 - Frame structure and uplink transmission schemes for massive machine type communication systems - Google Patents

Abstract

An apparatus is configured to be employed within a base station. The apparatus comprises baseband circuitry which includes a radio frequency (RF) interface and one or more processors. The one or more processors are configured to obtain massive machine type communications (mMTC) capabilities for a user equipment (UE) device. The one or more processors are configured to assign frequency-time resource units (FTRUs) for the UE device according to the mMTC capabilities; generate a frame structure based on the assigned FTRU and the mMTC capabilities; generate downlink data using the generated frame structure; and provide the downlink data to the RF interface for transmission to the UE device. The one or more processors can also be configured to generate uplink assistance information for a user equipment (UE) device, generate feedback based on the uplink assistance information and provide the feedback to the RF interface for transmission to the UE device.

Description

FRAME STRUCTURE AND UPLINK TRANSMISSION SCHEMES FOR MASSIVE MACHINE TYPE COMMUNICATION SYSTEMS

FIELD

[0001] Various embodiments generally relate to the field of wireless communications.

RELATED APPLICATIONS

[0002] This application claims the benefit of Provisional Application No. 62/383,105, filed September 2, 2016 and Provisional Application No. 62/397,697 filed September 21 , 2016, which are incorporated by reference.

BACKGROUND

[0003] Wireless or mobile communication involves wireless communication between two or more devices. The communication requires resources to transmit data from one device to another and/or to receive data at one device from another.

[0004] Wireless communication typically has limited resources in terms of time and frequency. The utilization of these limited resources can impact communication data rate, reliability, latency and the like. Underutilization of these resources can occur, thereby degrading communication, reliability, data rate and the like. Additionally, higher data rates are increasingly used or required for wireless communication.

[0005] What is needed are techniques to facilitate allocation of resources used for wireless communications.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 illustrates a block diagram of an example wireless communications network environment for a network device (e.g., a UE or an eNB) according to various aspects or embodiments.

[0007] FIG. 2 illustrates another block diagram of an example of wireless

communications network environment for a network device (e.g., a UE or an eNB) according to various aspects or embodiments.

[0008] FIG. 3 another block diagram of an example of wireless communications network environment for network device (e.g., a UE or an eNB) with various interfaces according to various aspects or embodiments. [0009] FIG. 4 is a diagram illustrating an architecture of a system using a frame structure and/or design for mMTC with mobile communication systems in accordance with some embodiments.

[0010] FIG. 5 is a diagram illustrating an architecture of a system using a frame structure and/or design for mMTC with mobile communication systems in accordance with some embodiments.

[0011] FIG. 6 is a diagram illustrating frequency-time resources in accordance with some embodiments.

[0012] FIG. 7 is a table illustrating different FTRU formats in accordance with some embodiments.

[0013] FIG. 8 is a diagram illustrating a cell specific frame structure having a fixed duration in accordance with some embodiments.

[0014] FIG. 9 is a diagram illustrating a cell specific frame structure having a varied subframe durations in accordance with some embodiments.

[0015] FIG. 10 is a diagram illustrating a cell specific frame structure based on varied coverages for UEs in accordance with some embodiments.

[0016] FIG. 1 1 is a diagram illustrating a frame structure using repetition based scheduling in accordance with some embodiments.

[0017] FIG. 12 is a diagram illustrating schemes for PDCCH repetitions in a cell specific frame structure.

[0018] FIG. 13 is a diagram illustrating a different subframe durations in a frame structure for varied latency requirements in accordance with some embodiments.

[0019] FIG. 14 is a diagram illustrating a different subcarrier spacings in a frame structure for varied latency requirements in accordance with some embodiments.

[0020] FIG. 15 is a diagram illustrating a frame structure for varied bandwidth capabilities in accordance with some embodiments.

[0021] FIG. 16 is a diagram illustrating a frame structure for varied coverage levels in accordance with some embodiments.

[0022] FIG. 17 is a diagram illustrating a frame structure to facilitate coexistence with different bandwidth or latency requirements.

[0023] FIG. 18 is a diagram illustrating a frame structures as perceived by UE devices.

[0024] FIG. 19 is a flow diagram illustrating a method for using a frame structure for resource allocation for mobile communication systems in accordance with some embodiments. [0025] FIG. 20 is a diagram that illustrates an example of SINR based feedback in accordance with some embodiments.

[0026] FIG. 21 is a table illustrating an example SINR quantization function in accordance with some embodiments.

[0027] FIG. 22 is a diagram illustrating an example of an eNB providing network feedback on a PRB basis.

[0028] FIG. 23 is a table depicting suitable uplink interference level in accordance with some embodiments.

[0029] Fig. 24 is a flow diagram illustrating a method of performing uplink

transmissions in accordance with some embodiments.

DETAILED DESCRIPTION

[0030] The present disclosure will now be described with reference to the attached drawing figures, wherein like reference numerals are used to refer to like elements throughout, and wherein the illustrated structures and devices are not necessarily drawn to scale. 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 various embodiments. However, it will be apparent to those skilled in the art having 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 various embodiments with unnecessary detail. Embodiments herein may be related to RAN1 and 5G.

[0031] As utilized herein, terms "component," "system," "interface," and the like are intended to refer to a computer-related entity, hardware, software (e.g., in execution), and/or firmware. For example, a component can be a processor, a process running on a processor, a controller, an object, an executable, a program, a storage device, and/or a computer with a processing device. By way of illustration, an application running on a server and the server can also be a component. One or more components can reside within a process, and a component can be localized on one computer and/or distributed between two or more computers. A set of elements or a set of other components can be described herein, in which the term "set" can be interpreted as "one or more." [0032] Further, these components can execute from various computer readable storage media having various data structures stored thereon such as with a module, for example. The components can communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network, such as, the Internet, a local area network, a wide area network, or similar network with other systems via the signal).

[0033] As another example, a component can be an apparatus with specific

functionality provided by mechanical parts operated by electric or electronic circuitry, in which the electric or electronic circuitry can be operated by a software application or a firmware application executed by one or more processors. The one or more processors can be internal or external to the apparatus and can execute at least a part of the software or firmware application. As yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts; the electronic components can include one or more processors therein to execute software and/or firmware that confer(s), at least in part, the functionality of the electronic components.

[0034] Use of the word exemplary is intended to present concepts in a concrete fashion. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless specified otherwise, or clear from context, "X employs A or B" is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then "X employs A or B" is satisfied under any of the foregoing instances. In addition, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form. Furthermore, to the extent that the terms "including", "includes", "having", "has", "with", or variants thereof are used in either the detailed description and the claims, such terms are intended to be inclusive in a manner similar to the term

"comprising".

[0035] As used herein, the term "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, 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 the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

[0036] Wireless/mobile communication typically has limited resources in terms of time and frequency. The utilization of these limited resources can impact

communication data rate, reliability, latency and the like. Underutilization of these resources can occur, thereby degrading communication, reliability, data rate and the like. Additionally, higher data rates are increasingly used or required for wireless communication.

[0037] Massive machine type communications (mMTC) introduces new

requirements and design considerations to a 3GPP system. 5G mMTC takes into account key performance indicators (KPIs) including battery life, connection density and coverage.

[0038] In one example, a target for UE battery life is that it should exceed 1 0 years for mMTC UEs at an extreme coverage, i.e. MCL of 164 dB, where it uploads 200 bytes UL per day followed by 20 bytes DL. A target for connection density is 1 ,000,000 device/km² in an urban environment. An example target for coverage is to have a maximum coupling loss (MCL) of 164 dB for both uplink and downlink for a data rate of 160 bps.

[0039] In addition to the KPIs, the 5G mMTC design should support variety range of services with different quality of service (QoS) and latency requirements. For instance, a mMTC UE device can be a smart meter with limited communication requirements and capabilities (e.g., devices without an IMS client). The smart meter records a certain usage and reports small payload to the network once every day, week or month. On the other hand, the 5G mMTC UE device should be able to support real time services including real time voice (e.g., at least 24.4Kbps) and/or real time video (e.g., at least 1 Mbps). For instance, a target is that the 5G mMTC UE device is capable to address the data rate demands of various applications such as wearables with voice and audio/video streaming directly to the network (without using the smart phone as aggregator node), surveillance systems with video streaming support, devices catering to healthcare and assisted living use cases with voice-based guidance in case of emergencies, etc. While the 5G mMTC design should release several existing LTE design constraints and provide a flexible and scalable design for future MTC

applications, reusing a wholly LTE centered design is difficult due to the following limitations: [0040] The existence of always-on signals such as CRS within LTE makes flexibility of LTE more challenging for MTC-centric applications. For example, in order not to affect performance of legacy LTE devices, eMTC/NB-IOT design requires rate-matching around cell-specific RS, which reduces the flexibility for future evolution for MTC application based on an underlying LTE physical layer.

[0041] In order to support different bandwidth, the LTE-based eMTC and NB-IOT designs utilize different signal/channel designs for sync/broadcast/control and data channels. This implies that the 5G mMTC design cannot straightforwardly extend the LTE eMTC/NB-IOT designs in a scalable and flexible manner.

[0042] In LTE the frame structure is fixed. Therefore, due to the lack of scalability in time domain, LTE frame structure design is not self-contained and cannot support the repetitions within the same subframe. As a result, in eMTC design in order to improve coverage new channels (such as M-PDCCH, M-PDSCH, M-PUSCH,..etc) as well as new features such as cross subframe scheduling have been introduced to

accommodate different repetition levels within multiple subframes.

[0043] In LTE the minimum supportable bandwidth is 1 .4MHz. Due to the lack of flexibility in frequency domain, LTE design cannot be easily extended to support ultra- low-cost devices with bandwidth of 180KHz.

[0044] Thus, various embodiments are shown that utilize frame

configurations/structures based on varied mMTC considerations/capabilities. The frame configurations also consider available resources, resource utilization and the like.

Further, the various embodiments include techniques for performing and selecting uplink (UL) transmissions, such as autonomous and non-autonomous.

[0045] FIG. 1 illustrates an architecture of a system 100 of a network in accordance with some embodiments. The system 100 is shown to include a user equipment (UE) 101 and a UE 102. The UEs 101 and 1 02 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but can also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

[0046] In some embodiments, any of the UEs 101 and 102 can comprise an Internet of Things (loT) UE, which can comprise a network access layer designed for low-power loT applications utilizing short-lived UE connections. An loT UE can utilize technologies such as machine-to-machine (M2M) or machine-type communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or loT networks. The M2M or MTC exchange of data can be a machine-initiated exchange of data. An loT network describes interconnecting loT UEs, which can include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The loT UEs can execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the loT network.

[0047] The UEs 101 and 102 can be configured to connect, e.g., communicatively couple, with a radio access network (RAN) 1 10— the RAN 1 10 can be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. The UEs 101 and 102 utilize connections 103 and 104, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 103 and 104 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, 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 PTT over Cellular (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 the like.

[0048] In this embodiment, the UEs 101 and 1 02 can further directly exchange communication data via a ProSe interface 105. The ProSe interface 105 can

alternatively be referred to as a sidelink interface comprising one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

[0049] The UE 102 is shown to be configured to access an access point (AP) 106 via connection 107. The connection 107 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.1 1 protocol, wherein the AP 106 would comprise a wireless fidelity (WiFi®) router. In this example, the AP 1 06 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below).

[0050] The RAN 1 1 0 can include one or more access nodes that enable the connections 1 03 and 104. These access nodes (ANs) can be referred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), next Generation NodeBs (gNB), RAN nodes, and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). A network device as referred to herein can include any one of these APs, ANs, UEs or any other network component. The RAN 1 10 can include one or more RAN nodes for providing macrocells, e.g., macro RAN node 1 1 1 , and one or more RAN nodes for providing femtocells or picocells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells), e.g., low power (LP) RAN node 1 12.

[0051] Any of the RAN nodes 1 1 1 and 1 12 can terminate the air interface protocol and can be the first point of contact for the UEs 101 and 102. In some embodiments, any of the RAN nodes 1 1 1 and 1 12 can fulfill various logical functions for the RAN 1 1 0 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink (UL) and downlink (DL) dynamic radio resource

management and data packet scheduling, and mobility management.

[0052] In accordance with some embodiments, the UEs 101 and 102 can be configured to communicate using Orthogonal Frequency-Division Multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 1 1 1 and 1 1 2 over a multicarrier communication channel in accordance 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 signals can comprise a plurality of orthogonal subcarriers.

[0053] In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 1 1 1 and 1 12 to the UEs 101 and 1 02, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for 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 a resource grid is denoted as a resource element. Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements; in the frequency domain, this can represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

[0054] The physical downlink shared channel (PDSCH) can carry user data and higher-layer signaling to the UEs 101 and 102. The physical downlink control channel (PDCCH) can carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It can also inform the UEs 101 and 102 about the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE 102 within a cell) can be performed at any of the RAN nodes 1 1 1 and 1 12 based on channel quality information fed back from any of the UEs 101 and 102. The downlink resource assignment information can be sent on the PDCCH used for (e.g., assigned to) each of the UEs 101 and 1 02.

[0055] The PDCCH can use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols can first be organized into quadruplets, which can then be permuted using a sub-block interleaver for rate matching. Each PDCCH can be transmitted using one or more of these CCEs, where each CCE can correspond to nine sets of four physical resource elements known as resource element groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition. There can be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=1 , 2, 4, or 8).

[0056] Some embodiments can use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments can utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH can be transmitted using one or more enhanced the control channel elements (ECCEs). Similar to above, each ECCE can correspond to nine sets of four physical resource elements known as an enhanced resource element groups (EREGs). An ECCE can have other numbers of EREGs in some situations.

[0057] The RAN 1 1 0 is shown to be communicatively coupled to a core network (CN) 1 20— via an S1 interface 1 1 3. In embodiments, the CN 120 can be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN. In this embodiment the S1 interface 1 13 is split into two parts: the S1 -U interface 1 14, which carries traffic data between the RAN nodes 1 1 1 and 1 12 and the serving gateway (S-GW) 122, and the S1 -mobility management entity (MME) interface 1 15, which is a signaling interface between the RAN nodes 1 1 1 and 1 12 and MMEs 121 .

[0058] In this embodiment, the CN 1 20 comprises the MMEs 121 , the S-GW 122, the Packet Data Network (PDN) Gateway (P-GW) 123, and a home subscriber server (HSS) 124. The MMEs 121 can be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MMEs 121 can manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 124 can comprise a database for network users, including subscription-related information to support the network entities' handling of

communication sessions. The CN 120 can comprise one or several HSSs 124, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS 124 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.

[0059] The S-GW 122 can terminate the S1 interface 1 13 towards the RAN 1 1 0, and routes data packets between the RAN 1 10 and the CN 1 20. In addition, the S-GW 122 can be a local mobility anchor point for inter-RAN node handovers and also can provide an anchor for inter-3GPP mobility. Other responsibilities can include lawful intercept, charging, and some policy enforcement.

[0060] The P-GW 123 can terminate an SGi interface toward a PDN. The P-GW 123 can route data packets between the CN network 120 and external networks such as a network including the application server 130 (alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 125. Generally, the application server 130 can be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc.). In this embodiment, the P-GW 123 is shown to be communicatively coupled to an application server 130 via an IP communications interface 125. The application server 130 can 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 UEs 1 01 and 102 via the CN 120.

[0061] The P-GW 123 can further be a node for policy enforcement and charging data collection. Policy and Charging Enforcement Function (PCRF) 126 is the policy and charging control element of the CN 120. In a non-roaming scenario, there can be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with a UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local breakout of traffic, there can be two PCRFs associated with a UE's IP-CAN session: a Home PCRF (H-PCRF) within a HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN). The PCRF 126 can be communicatively coupled to the application server 130 via the P-GW 123. The application server 130 can signal the PCRF 126 to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters. The PCRF 126 can provision this rule into a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate traffic flow template (TFT) and QoS class of identifier (QCI), which commences the QoS and charging as specified by the application server 130.

[0062] In one or more embodiments, IMS services can be identified more accurately in a paging indication, which can enable the UEs 101 , 102 to differentiate between PS paging and IMS service related paging. As a result, the UEs 101 , 102 can apply preferential prioritization for IMS services as desired based on any number of requests by any application, background searching (e.g., PLMN searching or the like), process, or communication. In particular, the UEs 1 01 , 102 can differentiate the PS domain paging to more distinguishable categories, so that IMS services can be identified clearly in the UEs 101 , 102 in comparison to PS services. In addition to a domain indicator (e.g., PS or CS), a network (e.g., CN 120, RAN 1 10, AP 106, or combination thereof as an eNB or the other network device) can provide further, more specific information with the TS 36.331 -Paging message, such as a "paging cause" parameter. The UE can use this information to decide whether to respond to the paging, possibly interrupting some other procedure like an ongoing PLMN search.

[0063] In one example, when UEs 101 , 102 can be registered to a visited PLMN (VPLMN) and performing PLMN search (i.e., background scan for a home PLMN (HPLMN) or a higher priority PLMN), or when a registered UE is performing a manual PLMN search, the PLMN search can be interrupted in order to move to a connected mode and respond to a paging operation as part of a MT procedure / operation.

Frequently, this paging could be for PS data (non-IMS data), where, for example, an application server 130 in the NW wants to push to the UE 101 or 102 for one of the many different applications running in / on the UE 101 or 1 02, for example. Even though the PS data could be delay tolerant and less important, in legacy networks the paging is often not able to be ignored completely, as critical services like an IMS call can be the reason for the PS paging. The multiple interruptions of the PLMN search caused by the paging can result in an unpredictable delay of the PLMN search or in the worst case even in a failure of the procedure, resulting in a loss of efficiency in network

communication operations. A delay in moving to or handover to a preferred PLMN (via manual PLMN search or HPLMN search) in a roaming condition can incur more roaming charges on a user as well.

[0064] FIG. 2 illustrates example components of a network device 200 in accordance with some embodiments. In some embodiments, the device 200 can include application circuitry 202, baseband circuitry 204, Radio Frequency (RF) circuitry 206, front-end module (FEM) circuitry 208, one or more antennas 210, and power management circuitry (PMC) 21 2 coupled together at least as shown. The components of the illustrated device 200 can be included in a UE 101 , 102 or a RAN node 1 1 1 , 1 12, AP, AN, eNB or other network component. In some embodiments, the device 200 can include less elements (e.g., a RAN node can not utilize application circuitry 202, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the network device 200 can include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below can be included in more than one device (e.g., said circuitries can be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

[0065] The application circuitry 202 can include one or more application processors. For example, the application circuitry 202 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors can be coupled with or can include memory/storage and can be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 200. In some embodiments, processors of application circuitry 202 can process IP data packets received from an EPC.

[0066] The baseband circuitry 204 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 204 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 206 and to generate baseband signals for a transmit signal path of the RF circuitry 206. Baseband processing circuity 204 can interface with the application circuitry 202 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 206. For example, in some embodiments, the baseband circuitry 204 can include a third generation (3G) baseband processor 204A, a fourth generation (4G) baseband processor 204B, a fifth generation (5G) baseband processor 204C, or other baseband processor(s) 204D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), si2h generation (6G), etc.). The baseband circuitry 204 (e.g., one or more of baseband processors 204A-D) can handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 206. In other embodiments, some or all of the functionality of baseband processors 204A-D can be included in modules stored in the memory 204G and executed via a Central Processing Unit (CPU) 204E. The radio control functions can include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 204 can include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments,

encoding/decoding circuitry of the baseband circuitry 204 can include convolution, tail- biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and can include other suitable functionality in other embodiments.

[0067] In some embodiments, the baseband circuitry 204 can include one or more audio digital signal processor(s) (DSP) 204F. The audio DSP(s) 204F can be include elements for compression/decompression and echo cancellation and can include other suitable processing elements in other embodiments. Components of the baseband circuitry can be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 204 and the application circuitry 202 can be implemented together such as, for example, on a system on a chip (SOC).

[0068] In some embodiments, the baseband circuitry 204 can provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 204 can support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 204 is configured to support radio communications of more than one wireless protocol can be referred to as multi-mode baseband circuitry.

[0069] RF circuitry 206 can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various

embodiments, the RF circuitry 206 can include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 206 can include a receive signal path which can include circuitry to down-convert RF signals received from the FEM circuitry 208 and provide baseband signals to the baseband circuitry 204. RF circuitry 206 can also include a transmit signal path which can include circuitry to up- convert baseband signals provided by the baseband circuitry 204 and provide RF output signals to the FEM circuitry 208 for transmission.

[0070] In some embodiments, the receive signal path of the RF circuitry 206 can include mixer circuitry 206a, amplifier circuitry 206b and filter circuitry 206c. In some embodiments, the transmit signal path of the RF circuitry 206 can include filter circuitry 206c and mixer circuitry 206a. RF circuitry 206 can also include synthesizer circuitry 206d for synthesizing a frequency for use by the mixer circuitry 206a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 206a of the receive signal path can be configured to down-convert RF signals received from the FEM circuitry 208 based on the synthesized frequency provided by synthesizer circuitry 206d. The amplifier circuitry 206b can be configured to amplify the down- converted signals and the filter circuitry 206c can be a low-pass filter (LPF) or bandpass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals can be provided to the baseband circuitry 204 for further processing. In some embodiments, the output baseband signals can be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 206a of the receive signal path can comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0071] In some embodiments, the mixer circuitry 206a of the transmit signal path can be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 206d to generate RF output signals for the FEM circuitry 208. The baseband signals can be provided by the baseband circuitry 204 and can be filtered by filter circuitry 206c.

[0072] In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path can include two or more mixers and can be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path can include two or more mixers and can be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a can be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path can be configured for super-heterodyne operation.

[0073] In some embodiments, the output baseband signals and the input baseband signals can be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals can be digital baseband signals. In these alternate embodiments, the RF circuitry 206 can include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 204 can include a digital baseband interface to communicate with the RF circuitry 206.

[0074] In some dual-mode embodiments, a separate radio IC circuitry can be provided for processing signals for each spectrum, although the scope of the

embodiments is not limited in this respect.

[0075] In some embodiments, the synthesizer circuitry 206d can be a fractional-N synthesizer or a fractional N/N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers can be suitable. For example, synthesizer circuitry 206d can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[0076] The synthesizer circuitry 206d can be configured to synthesize an output frequency for use by the mixer circuitry 206a of the RF circuitry 206 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 206d can be a fractional N/N+1 synthesizer.

[0077] In some embodiments, frequency input can be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input can be provided by either the baseband circuitry 204 or the applications processor 202 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) can be determined from a look-up table based on a channel indicated by the applications processor 202.

[0078] Synthesizer circuitry 206d of the RF circuitry 206 can include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider can be a dual modulus divider (DMD) and the phase accumulator can be a digital phase accumulator (DPA). In some embodiments, the DMD can be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL can 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 can be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0079] In some embodiments, synthesizer circuitry 206d can be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency can be a LO frequency (fLO). In some embodiments, the RF circuitry 206 can include an IQ/polar converter.

[0080] FEM circuitry 208 can include a receive signal path which can include circuitry configured to operate on RF signals received from one or more antennas 210, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 206 for further processing. FEM circuitry 208 can also include a transmit signal path which can include circuitry configured to amplify signals for transmission provided by the RF circuitry 206 for transmission by one or more of the one or more antennas 21 0. In various embodiments, the amplification through the transmit or receive signal paths can be done solely in the RF circuitry 206, solely in the FEM 208, or in both the RF circuitry 206 and the FEM 208.

[0081] In some embodiments, the FEM circuitry 208 can include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry can include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry can include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 206). The transmit signal path of the FEM circuitry 208 can include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 206), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 210). [0082] In some embodiments, the PMC 212 can manage power provided to the baseband circuitry 204. In particular, the PMC 212 can control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 212 can often be included when the device 200 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 21 2 can increase the power conversion efficiency while providing desirable implementation size and heat dissipation

characteristics.

[0083] While FIG. 2 shows the PMC 212 coupled only with the baseband circuitry 204. However, in other embodiments, the PMC 2 12 can be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 202, RF circuitry 206, or FEM 208.

[0084] In some embodiments, the PMC 212 can control, or otherwise be part of, various power saving mechanisms of the device 200. For example, if the device 200 is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it can enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 200 can power down for brief intervals of time and thus save power.

[0085] If there is no data traffic activity for an extended period of time, then the device 200 can transition off to an RRCJdle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 200 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 200 does not receive data in this state, in order to receive data, it transitions back to RRC_Connected state.

[0086] An additional power saving mode can allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device can be unreachable to the network and can power down completely. Any data sent during this time can incur a large delay with the delay presumed to be acceptable.

[0087] Processors of the application circuitry 202 and processors of the baseband circuitry 204 can be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 204, alone or in combination, can be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 204 can utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer 3 can comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 can comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 can comprise a physical (PHY) layer of a UE/RAN node. Each of these layers can be implemented to operate one or more processes or network operations of embodiments / aspects herein.

[0088] In addition, the memory 204G can comprise one or more machine-readable medium / media including instructions that, when performed by a machine or

component herein cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to embodiments and examples described herein. It is to be understood that aspects described herein can be implemented by hardware, software, firmware, or any combination thereof. When implemented in software, functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium (e.g., the memory described herein or other storage device). Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media or a computer readable storage device can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD- ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or other tangible and/or non-transitory medium, that can be used to carry or store desired information or executable instructions. Also, any connection can also be termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.

[0089] In general, there is a move to provide network services for the packet domain. The earlier network services like UMTS or 3G and predecessors (2G) configured a CS domain and a packet domain providing different services, especially CS services in the CS domain as well as voice services were considered to have a higher priority because consumers demanded an immediate response. Based on the domain that the paging was received, the device 200 could assign certain priority for the incoming transaction. Now with LTE / 5G most services are moving to the packet domain. Currently, the UE (e.g., 1 01 , 102, or device 200) can get paging for a packet service without knowing any further information about the paging of the MT procedure, such as whether someone is calling on a line, a VoIP call, or just some packet utilized from Facebook, other application service, or other similar MT service. As such, a greater opportunity exists for further delays without the possibility for the UE to discriminate between the different application packets that could initiate a paging and also give a different priority to it based on one or more user preferences. This can could be important for the UE because the UE might be doing other tasks more vital for resource allocation.

[0090] In one example, a UE (e.g., 101 , 102, or device 200) could be performing a background search for other PLMNs. This is a task the UE device 200 could do in regular intervals if it is not connected on its own home PLMN or a higher priority PLMN, but roaming somewhere else. A higher priority could be a home PLMN or some other PLMNs according to a list provided by the provider or subscriber (e.g., HSS 124).

Consequently, if a paging operation arrives as an MT service and an interruption results, such that a start and begin operation are executed, a sufficient frequency of these interruptions could cause the UE to never complete a background search in a reasonable way. This is one way where it would be advantageous for the UE or network device to know that the interruption is only a packet service, with no need to react to it immediately, versus an incoming voice call that takes preference immediately and the background scan should be postponed.

[0091] Additionally, the device 200 can be configured to connect or include multiple subscriber identity / identification module (SIM) cards / components, referred to as dual SIM or multi SIM devices. The device 200 can operate with a single transmit and receive component that can coordinate between the different identities from which the SIM components are operating. As such, an incoming voice call should be responded to as fast as possible, while only an incoming packet for an application could be relatively ignored in order to utilize resources for the other identity (e.g., the voice call or SIM component) that is more important or has a higher priority from a priority list / data set / or set of user device preferences, for example. This same scenario can also be utilized for other operations or incoming data, such as with a PLMN background search such as a manual PLMN search, which can last for a long period of time since, especially with a large number of different bands from 2G, etc. With an ever increasing number of bands being utilized in wireless communications, if paging interruptions come in between the operations already running without distinguishing between the various packet and real critical services such as voice, the network devices can interpret this manual PLMN search to serve and ensure against a drop or loss of any increment voice call, with more frequent interruptions in particular.

[0092] As stated above, even though in most of these cases the PS data is delay tolerant and less important, in legacy networks the paging cannot be ignored

completely, as critical services like an IMS call can be the reason for the PS paging. The multiple interruptions of a PLMN search caused by the paging can result in an unpredictable delay of the PLMN search or in the worst case even in a failure of the procedure. Additionally, a delay in moving to preferred PLMN (via manual PLMN search or HPLMN search) in roaming condition can incur more roaming charges on user.

Similarly, in multi-SIM scenario when UE is listening to paging channel of two networks simultaneously and has priority for voice service, a MT IMS voice call can be interpreted as "data" call as indicated in MT paging message and can be preceded by MT Circuit Switched (CS) paging of an other network or MO CS call initiated by user at same time. As such, embodiments / aspects herein can increase the call drop risk significantly for the SIM using IMS voice service.

[0093] In embodiments, 3GPP NW can provide further granular information about the kind of service the network is paging for. For example, the Paging cause parameter could indicate one of the following values / classes / categories: 1 ) IMS voice/video service; 2) IMS SMS service; 3) IMS other services (not voice/video/SMS-related; 4) any IMS service; 5) Other PS service (not IMS-related). In particular, a network device (e.g., an eNB or access point) could only be discriminating between IMS and non-IMS services could use 4) and 5), whereas a network that is able to discriminate between different types of IMS services (like voice/video call, SMS, messaging, etc.) could use 3) instead of 4) to explicitly indicate to the UE that the paging is for an IMS service different from voice/video and SMS. By obtaining this information UE may decide to suspend PLMN search only for critical services like incoming voice/video services.

[0094] In other aspects, dependent on the service category (e.g., values or classes 1 -5 above), the UE 101 , 102, or device 200 can memorize that there was a paging to which it did not respond, and access the network later, when the PLMN search has been completed and the UE decides to stay on the current PLMN. For example, if the reason for the paging was a mobile terminating IMS SMS, the MME can then inform the HSS (e.g., 124) that the UE is reachable again, and the HSS 124 can initiate a signaling procedure which will result in a delivery of the SMS to the UE once resources are more available or less urgent for another operation / application / or category, for example. To this purpose the UE 101 , 102, or 200 could initiate a periodic tau area update (TAU) procedure if the service category in the Paging message indicated "IMS SMS service", for example.

[0095] FIG. 3 illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry 204 of FIG. 2 can comprise processors 204A-204E and a memory 204G utilized by said processors. Each of the processors 204A-204E can include a memory interface, 304A-304E, respectively, to send/receive data to/from the memory 204G.

[0096] The baseband circuitry 204 can further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 312 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 204), an application circuitry interface 314 (e.g., an interface to send/receive data to/from the application circuitry 202 of FIG. 2), an RF circuitry interface 316 (e.g., an interface to send/receive data to/from RF circuitry 206 of FIG. 2), a wireless hardware connectivity interface 31 8 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 320 (e.g., an interface to send/receive power or control signals to / from the PMC 21 2.

[0097] FIG. 4 is a diagram illustrating an architecture of a system 400 using a frame structure and/or design for mMTC with mobile communication systems in accordance with some embodiments. The system 400 can be utilized with the above embodiments and variations thereof, including the system 100 described above. The system 400 is provided as an example and it is appreciated that suitable variations are contemplated.

[0098] The system 400 includes a network device 401 and a node 402. The device 401 is shown as a UE device and the node 402 is shown as an eNB for illustrative purposes. It is appreciated that the UE device 401 can be other network devices, such as Aps, ANs and the like. It is also appreciated that the eNB 402 can be other nodes or access nodes (ANs), such as BSs, gNB, RAN nodes and the like. Other network or network devices can be present and interact with the device 401 and/or the node 402.

[0099] Downlink (DL) transmissions occur from the eNB 402 to the UE 401 whereas uplink (UL) transmissions occur from the UE 401 to the eNB 402. The downlink transmissions utilize a DL control channel and a DL data channel. The uplink transmissions utilize an UL control channel and a UL data channel. The various channels can be different in terms of direction, link to another eNB and the like.

[00100] The UE device 401 supports Massive machine type communications (mMTC) and can be referred to as an mUE device. It is appreciated that logical and physical channels can be preceded by an "m" to indicate that they support mMTC.

[00101 ] The system 400 utilizes architecture configured to support mMTC capabilities, such as to support various repetition levels to improve coverage, support mMTC UE devices with different bandwidth capabilities, support mMTC UE devices with varied latency requirements and the like. Thus, the mMTC capabilities include bandwidth capabilities, coverage, coverage levels, latency requirements/capabilities, quality of service (QOS), repetition levels, data rates and the like. The mMTC capabilities can be UE specific, for a cell, for a group of UE devices, and the like.

[00102] The frame structure uses frequency-time resource units (FTRU), which is a scheduling unit or minimum scheduling unit to support the mMTC capabilities.

Additionally or alternately, the frame structure uses frequency-time slicing patterns that allocate time and frequency resources as patterns. A pattern is a collection or arrangement of frequency-time slices. A frequency-time slice is an arrangement of resources or FTRUs typically associated with a UE, such as the UE 401 .

[00103] The node 402 obtains mMTC capabilities for the UE 401 as shown at item 404. The capabilities, as shown above, can include latency, data rate, bandwidth, coverage, and the like.

[00104] The node 402 is configured to generate an uplink (UL) frame structure and a downlink (DL) frame structure based on the mMTC capabilities. The UL frame structure and the DL frame structure assign frequency and time resource to the UE device 401 and/or other UE devices.

[00105] The UL frame structure and the DL frame structure include a control region and a data region. These regions can be fixed and/or variable. The UL control region can be a PUCCH or mPUCCH (supports mMTC) and the UL data region can be a PUSCH or mPUSCH (supports mMTC). Similarly, the DL control region can be a PDCCH or mPDCCH (supports mMTC) and the DL data region can be a PDSCH or mPDSCH (supports mMTC).

[00106] The UL and DL frame structure can be pre-determined as a network and/or can be signaled or otherwise provided to the UE device 401 .

[00107] In one example, the node 402 configures the frame structures based on frequency-time resource units (FTRU) that include a number of subcarriers, number of slots, a modulation type, a coding rate, and a repetition level that provide the nMTC capabilities/requirements.

[00108] In another example, the node 402 configures the frame structures using slicing patterns where slices are assigned to one or more UE devices, including the UE device 401 .

[00109] In another example, the node 402 configures the frame structures by altering lengths of subframes, control regions and data regions.

[00110] In another example, the node 402 configures frequency-time slicing or patterns to accommodate a coverage or coverage level of the mMTC for the UE 401 .

[00111 ] In another example, the node 402 configures the structure to include inter- frame repetition.

[00112] In another example, the node 402 configures the structure to include intra- frame repetition.

[00113] In another example, the node 402 configures slices of the structure with smaller subcarrier spacing for narrower bandwidth or narrowband or with larger subcarrier spacing for wider bandwidth or wideband.

[00114] In another example, the node 402 includes a guardband between slices for different UE devices, including the UE device 401 to mitigate subcarrier interference.

[00115] The node 402 generates a downlink transmission in accordance with the DL frame structure at 408. The DL transmission is received and decoded by the UE device 401 . The UE device 401 can perceive a different frame structure than that transmitted by the node 402, as explained in greater detail below.

[00116] The UE device 401 generates an uplink transmission in accordance with the UL frame structure at 410.

[00117] It is appreciated that the system 400 can be used with additional nodes and/or UE devices.

[00118] FIG. 5 is a diagram illustrating an architecture of a system 500 using a frame structure and/or design for mMTC with mobile communication systems in accordance with some embodiments. The system 500 can be utilized with the above embodiments and variations thereof, including the systems 100 and 400, described above. The system 500 is provided as an example and it is appreciated that suitable variations are contemplated.

[00119] The system 500 includes a group of UE devices 501 and a node 402. It is appreciated that the UE devices 501 can be other network devices, such as Aps, ANs and the like. It is also appreciated that the eNB 402 can be other nodes or access nodes (ANs), such as BSs, gNB, RAN nodes and the like. Other network or network devices can be present and interact with the device 401 and/or the node 402.

[00120] Downlink (DL) transmissions occur from the eNB 402 to the UEs 501 whereas uplink (UL) transmissions occur from the UE 401 to the eNB 402. The downlink transmissions utilize a DL control channel and a DL data channel. The uplink transmissions utilize an UL control channel and a UL data channel. The various channels can be different in terms of direction, link to another eNB and the like.

[00121 ] The UE devices 501 support Massive machine type communications (mMTC) and can be referred to as a mUE devices or mUEs.

[00122] The node 402 of FIG. 5 operates as the node 402 of FIG. 4 and generates the frames for the cell of UE devices 501 . The node 402 is configured to obtain mMTC capabilities for the group of UE devices and generate UL and DL frame structures based on the obtained mMTC capabilities. Thus, the UL and DL frame structures are cell based.

[00123] The frame structures include frequency-time slicing patterns. Each slice or pattern is assigned to one of the group of UEs 501 .

[00124] FIG. 6 is a diagram illustrating frequency-time resources 600 in accordance with some embodiments. The frequency-time resources 600 are provided as an example, also referred to as FTRUs can be configured to support mMTC capabilities. The resources 600 can be used with the systems 400, 500 and variations thereof. The frequency-time resources 600 are provided for illustrative purposes and as an example. It is appreciated that other suitable frequency-time resources and/or formats can be utilized.

[00125] The FTRUs are units in terms of frequency and time that can be allocated for downlink and/or uplink transmissions. The FTRUs can be arranged in slices or patterns and assigned/associated with particular UE devices.

[00126] The arrangement of a frame using FTRUs is also referred to as FTRU formats. The FTRU formats are defined based on mMTC frame or frame

characteristics, which include an underlying numerology, cyclic prefix (CP) length, the number of subcarriers in the frequency domain, the length or number of OFDM symbols in the time domain, the repetition level, the spreading factor in the time/frequency domain, a modulation scheme, a coding scheme, and the like.

[00127] The resources 600 are organized in slots and subcarriers. Time is depicted along an x-axis and frequency along a y-axis. The length in the time domain (x-axis) is shown as a slot. The slot is typically defined as having a fixed number of symbols, such as 1 symbol or 7 symbols. It is appreciated that other units of time can be used in addition to or instead of slots, such as, specifying a time/duration (e.g., 1 ms), a number of sybmols, subframe duration, frame duration and the like.

[00128] The frequency is depicted along the y-axis and is shown in terms of subcarriers, where each subcarrier occupies a band of frequency.

[00129] An FTRU can be specified in terms of one or more of the above

characteristics, such as 1 subcarrier and 24 slots, or 24 subcarriers and 1 slot.

[00130] Slices and/or patterns can be created using the FTRUs 600. For example, a slice for a first UE device can use 1 subcarrier and a length of 24 slots.

[00131 ] As another example, a second slice assigned to a second UE device can use

12 subcarriers and a length of 2 slots.

[00132] As another example, a third slice assigned to a third UE device can utilize 24 subcarriers and have a length of 1 slot.

[00133] As another example, a fourth slice assigned to a further UE device can utilize 12 subcarriers and have a length of 4 slots.

[00134] Thus, the frame structure can include one or more FTRU formats to allocate the resources.

[00135] FIG. 7 is a table illustrating different FTRU formats 700 in accordance with some embodiments. The FTRU formats 700 are can be configured to support mMTC capabilities. The FTRU formats 700 can be used with the systems 400, 500 and variations thereof. The FTRU formats 700 are provided for illustrative purposes and as an example. It is appreciated that other suitable frequency-time resources and/or formats can be utilized.

[00136] The table depicts four different FTRU formats that can be used to configure and/or structure a frame/subframe for uplink and/or downlink communications.

[00137] The FTRU formats 700 include an identity (ID), a number of subcarriers, a number of slots, a modulation, a coding rate and a repetition level. It is appreciated that other suitable FTRU formats can omit and/or include additional information.

[00138] A first format (1 ) includes 1 subcarrier, 24 slots, πί/2 binary phase shift keying

(BPSK) modulation, a coding rate of 1 /3 and a repetition level of 1 .

[00139] A second format (2) includes 1 subcarrier, 48 slots, πί/2 BPSK modulation, a coding rate of 1/3 and a repetition level of 2.

[00140] A third format (3) includes 12 subcarriers, 2 slots, QPSK modulation, a coding rate of 1 /2 and a repetition level of 1 . [00141 ] A fourth format (4) includes 24 subcarriers, 1 slot, QPSK modulation, a coding rate of 1 /2 and a repetition level of 1 .

[00142] It is appreciated that other suitable FTRU formats are contemplated. The FTRU formats can be defined by a network, network devices, nodes and the like at least partially based on mMTC capabilities.

[00143] FIG. 8 is a diagram illustrating a cell specific frame structure 800 having a fixed duration in accordance with some embodiments. The cell specific frame structure 800 can be configured to support mMTC capabilities. The cell specific frame structure 800 can be used with the systems 400, 500 and variations thereof. The cell specific frame structure 800 is provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00144] The cell specific frame structure 800 uses a fixed control region and subframe boundaries across UE devices within a cell. Thus, each of the UE devices follow the same frame structure. The UE devices are typically mMTC UE devices.

[00145] The structure 800 includes a control region and a data region. The regions are partitioned using a configured or pre-configured slicing pattern to support the mMTC UE devices with different mMTC capabilities.

[00146] Time is depicted along an x-axis and frequency along a y-axis.

[00147] A downlink frame structure includes a control region 801 and a data region 802. The control region 801 is fixed. The control region 801 and the data region 802 include varied frequency-time slices.

[00148] A node, such as the node 402, uses the slices to support mMTC UE devices having different mMTC capabilities, including bandwidth capabilities and coverages.

[00149] For example, slices A1 , A2, A3 and A4 are relatively larger slices and can be allocated to UE devices with higher bandwidth capabilities. Additionally, the slices A1 , A2, A3 and A4 can be used as repeated resources to facilitate coverage or coverage levels.

[00150] In contrast, slice B has narrower frequency resources/bandwidth and can be allocated to UE devices with lower bandwidth capabilities.

[00151 ] An uplink frame structure is shown with only a control region 803. The UL control region 803 is also configured to have a plurality of slices, which are configured to support the UE devices of the cell based on mMTC capabilities.

[00152] The node assigns slices of the frame to one or more UE devices based on UE device capabilities, including mMTC capabilities. Thus, each slice is assigned to a UE device. More than one slice can be assigned to a single UE device. [00153] The frame structure 800 has a subframe duration. It can be determined based on a weakest coverage of the UE devices within the cell. A relatively large delay would be expected between reception of the PDCCH and PDSCH or UL grant. The subframe duration can also be determined based on the strongest coverage of the UE devices within the cell. Then, cross-subframe scheduling for DCI, DL data and UL grant could be required to use a relatively large number of repetitions for the UEs that experience weak coverage. Thus, the node can be configured to adjust the subframe duration and configuration of slices on a semi-static basis according to the mMTC capabilities, including latency and QOS requirements, of the UE devices within the cell.

[00154] Thus, the node determines the subframe duration, configuration of slices, slice assignments and the like for the UE devices of the cell based on the mMTC capabilities.

[00155] FIG. 9 is a diagram illustrating a cell specific frame structure 900 having a varied subframe durations/lengths in accordance with some embodiments. The cell specific frame structure 900 can be configured to support mMTC capabilities. The cell specific frame structure 900 can be used with the systems 400, 500 and variations thereof. The cell specific frame structure 900 is provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00156] The frame structure 900 is determined by a network or node and includes a semi-static subframe duration and a semi-static control region duration. The frame structure 900 supports nested properties as shown in Fig. 9.

[00157] In one example a DL subcarrier spacing (SCS) of 3.75 kHz results in different subframe configurations or lengths, such as (4 ms, 16 ms), (8 ms, 32 ms) or (16 ms, 64 ms), where a first element denotes the control region or mPDCCH duration and the second element represents the data region or mPDSCH duration.

[00158] The frame structure 900 is determined by a node, such as the node 402, and is provided to one or more UE devices by signaling or other suitable mechanism.

[00159] In one example, synchronization signals and broadcast channels are fixed and independent of the frame/subframe configuration. In this example, a master information block (MIB) is used to convey frame structure information by including a frame configuration index. The receiving UE uses the index to lookup or determine the frame structure including subframe configurations/lengtch, control region duration, data region duration, and the like. [00160] In another example, frame structure information is carried by a system information block (SIB). In this example, common and fixed data regions across different subframes can carry the SIB message.

[00161 ] In yet another example, the frame structure, including the subframe configuration, is included in downlink control information (DCI) within a common search space. The DCI can be scheduled at an intersection of common control regions of different subframe configurations.

[00162] In FIG. 9, there are three different subrame configurations shown. A first subframe configuration 901 has a relatively short control region and data region lengths. A second subframe configuration 902 has longer control region and data region lengths. A third subframe configuration 903 has even longer control region and data region lengths.

[00163] The third subframe configuration 903 uses more time resources and can imply associated UE capabilities or mMTC capabilities that have a lower coverage, thus need the additional time resources. The first configuration uses less time resources and an associated UE can be assumed to have good coverage.

[00164] A common control region 904 is configured by a network or node to overlap or be within the three subframe configurations 901 , 902 and 903. Thus, UE devices can decode the common control region 904 to obtain new or updated subframe

configurations. In this example, the common control region 904 is the same length as the smallest control region of the first subframe configuration 901 .

[00165] Thus, the node is configured to determine and allocate varied subframe durations and assigned the allocated durations to one or more UE devices. In the example shown above, the configuration 901 can be allocated to a first UE device, the second configuration 902 can be allocated to a second UE device and the third configuration 903 can be allocated to a third UE device based on mMTC capabilities of the UE devices.

[00166] The assigned and allocated durations can be updated dynamically and/or periodically by the node.

[00167] FIG. 10 is a diagram illustrating a cell specific frame structure 1000 based on varied coverages for UEs in accordance with some embodiments. The frame structure 1000 includes time-frequency slicing patterns and can be configured to support mMTC capabilities for one or more UE devices. The cell specific frame structure 1000 can be used with the systems 400, 500 and variations thereof. The cell specific frame structure 1000 is provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00168] The node, such as an eNB, can determine configuration and assignment for frequency-time slicing based on mMTC capabilities for UE devices within a cell. The frequency-time slicing configuration or pattern can be broadcast by the node and van vary on a semi-static basis. The frequency-time pattern can be broadcast using a MIB, SIB and the like. For example, different slicing patterns can correspond to different bandwidth capabilities and/or coverage levels. The node can signal the UEs an index to the selected slicing pattern that the UEs should utilize.

[00169] For UE devices having lower coverage or lower coverage level capabitlies, variable power spectrum density (PSD) with PSD boosting can be used. In this case, all the slices may have the same area (time-frequency area) and PSD boosting improves the decoding probability. An underlying assumption is that for the UEs at the lower coverage level, the available frequency-time resources are spread across the time domain. Therefore, the node can perform PSD boosting for the UEs at the lower coverage level, under the constraint that the TX power should not be above a certain power.

[00170] A first configuration 1001 shows an example of the variable PSD scenario, where the eNB can apply PSD boosting on the slices 1004 allocated to a mMTC UE at extreme coverage.

[00171 ] A second configuration 1002 is an example of slicing for a uniform PSD scenario. In this case, a uniform PSD is assumed across different slices. A UE associated with the slices 1004 can utilize more utilize more frequency-time resources for repetition or spreading.

[00172] A third configuration 1003 also uses a variable PSD scenario. In this configuration, the resources are spread across frequency using time division

multiplexing (TDM). The eNB can apply boosting on the slices 1004. Therefore, a UE can decode the mPDCCH or mPDSCH earlier (UE requires less amount of time for decoding).

[00173] The slicing pattern for the control region (mPUCCH) may follow the data region (mPDCCH) pattern. Therefore, the UE can select/determine appropriate frequency-time resources to send the uplink control information (UCI). For instance, in

[00174] FIG. 1 1 is a diagram illustrating a frame structure 1 100 using repetition based scheduling in accordance with some embodiments. The frame structure 1 100 can be configured to support mMTC capabilities for one or more UE devices. The cell specific frame structure 1 1 00 can be used with the systems 400, 500 and variations thereof. The cell specific frame structure 1 1 00 is provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00175] The frame structure 1 100 is a cell-specific frame structure can utilize repetition-based scheduling cross multiple subframes to accommodate a large number of repetitions for both DL and UL data. For example, UE 1 is at extreme or low coverage and needs repetition to compensate for the extreme or low coverage. The downlink data for UE1 is provided in a data region for subframe n and repeated in a data region for subframe n+1 .

[00176] A node may repeat DL data across multiple subframes or mMTC subframes. Furthermore, the node can utilize different FTRU formats and/or slicing patterns to schedule UEs with different coverage levels for both DL and UL.

[00177] Additionally, the node provides a grant for UE2. The grant includes FTRU resources for the UE to provide uplink data as shown in the UL portion.

[00178] FIG. 12 is a diagram illustrating schemes for PDCCH repetitions in a cell specific frame structure 1 200. The frame structure 1200 can be configured to support mMTC capabilities for one or more UE devices. The cell specific frame structure 1200 can be used with the systems 400, 500 and variations thereof. The cell specific frame structure 1200 is provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00179] A cell-specific frame structure can utilize repetition-based DCI across multiple subframes to support a large number of repetitions for PDCCH. The DCI is repeated across X consecutive subframes, where is equal to the number of required repetition levels divided by the allowable number of PDCCH repetitions per mMTC subframe. The allowable number of PDCCH repetitions per subframe limits the number of PDCCH repetitions per subframe, therefore, it facilitates the scheduling of other UEs.

[00180] A first scheme 1201 for mPDCCH repetitions in cell-specific frame structure is where the PDCCH is repeated across multiple subframes and the PDSCH will be scheduled after the last repetition of PDCCH. Therefore, in this scheme 1201 , the UE waits untill the last repetition of PDCCH and then starts decoding the PDSCH.

[00181 ] A second scheme 1202 is where the PDCCH and PDSCH are scheduled simultaneously and repeated together across multiple subframes. In 1 202, if the UE is able to decode mPDCCH, it can then start decoding the PDSCH. Therefore, this scheme 1202 facilitates early decoding. However, it might require a higher buffer size at the UE.

[00182] FIG. 13 is a diagram illustrating a different subframe durations in a frame structure 1300 for varied latency requirements in accordance with some embodiments. The frame structure 1300 can be used with the systems 400, 500 and variations thereof. The cell specific frame structure 1300 is provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00183] A node can configure UE devices latency sensitive applications to have shorter subframe durations and other UE devices to have longer subframe durations. The UE devices for the latency sensitive applications are also referred as wideband UEs in that they use greater or more frequency resources. The UE devices with longer subframe durations are referred to as narrowband UE devices.

[00184] FTRUs with a small number OFDM symbols (e.g. 2-3 OFDM symbols) and more expansion across the frequency domain are more suitable for wideband UEs to facilitate latency reduction. On the other hand, the FTRUs with smaller bandwidth and more expansion in time domain are more suitable for the narrowband UEs to facilitate coverage.

[00185] The frame structure 1300 includes FTRUs and slices for narrowband requirements/capabilities and wideband requirements/capabilities. A narrowband slice 1301 is associated with a narrowband UE and has a longer subframe duration as shown by its length of its data region (mPDSCH). Wideband slices 1302 and 1303 are associated with one or more wideband UE devices and have a shorter subframe duration, but utilize more or wider frequency resources.

[00186] FIG. 14 is a diagram illustrating a different subcarrier spacings in a frame structure 1400 for varied latency requirements in accordance with some embodiments. The frame structure 1400 can be used with the systems 400, 500 and variations thereof. The frame structure 1400 is provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00187] A node can configure slices to have different subcarrier spacing in addition to subframe lengths. Latency sensitive applications, such as voice over internet protocol (VOIP), can utilize a shorter subcarrier spacing. For wideband applications, larger subcarrier spacings and, thus, shorter OFDM symbols can be used to reduce the subframe duration and satisfy latency requirements/capabilities. [00188] As an example, the frame structure 1400 includes slicing patterns for a narrowband and a wideband applications/capabilities. The narrowband has a subcarrier spacing of 3.75 kHz and the wideband has a subcarrier spacing of 15 kHz. A guard band of a selected spacing can be used to mitigate inter-subcarrier interference.

[00189] FIG. 15 is a diagram illustrating a frame structure 1500 for varied bandwidth capabilities in accordance with some embodiments. The frame structure 1500 can be used with the systems 400, 500 and variations thereof. The frame structure 1 500 is provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00190] It is appreciated that TDM mPUCCH or PUCCH can be used for wideband UEs or applications with faster channel state information (CSI) feedback. Similarly, FDM mPUCCH or PUCCH can be used for narrowband UEs or applications with larger maximum coupling loss (MCL).

[00191 ] The frame structure 1500 includes slicing for wideband (higher bandwidth) capabilities at 1501 that uses TDM and slicing for narrowband capabilities at 1502 that uses FDM for narrowband (lower bandwidth) capabilities.

[00192] For narrowband capabilities, spreading the control channel in time can be beneficial for coverage enhancement by using FDM.

[00193] FIG. 16 is a diagram illustrating a frame structure 1600 for varied coverage levels in accordance with some embodiments. The frame structure 1600 can be used with the systems 400, 500 and variations thereof. The frame structure 1600 is provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00194] For mMTC-specific frame structures, each UE can have a different perception of the frame structure in order to support different coverage levels and bandwidth capabilities.

[00195] The mMTC-specific frame structure provides time-domain scalability to support different repetition levels for mMTC UEs with different coverage levels.

[00196] FIG. 16 depicts multiple UE devices for mMTC applications and having mMTC capabilities. The UE devices include UE1 , UE2, and UE3.

[00197] The UE 3 has extreme/low coverage levels and, as a result, the control region and subframe duration are extended to accommodate larger number of repetitions as compared with the UE1 and UE2.

[00198] FIG. 17 is a diagram illustrating a frame structure 1700 to facilitate

coexistence with different bandwidth or latency requirements. The frame structure 1700 can be used with the systems 400, 500 and variations thereof. The frame structure

1700 is provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00199] The frame structure 1700 includes frequency-time slicing for narrowband

1701 and wideband 1702. Thus, both can coexist in the same frame structure. A guardband having a selected spacing can exist between the narrowband 1 701 and wideband 1702 patterns.

[00200] The wideband slices can have smaller subframe durations, but wider or larger frequency ranges to meet latency requirements/capabilities. The narrowband can have longer subframes, but narrower frequency ranges.

[00201 ] It is appreciated that other patterns are contemplated.

[00202] FIG. 18 is a diagram illustrating a frame structures 1 800 as perceived by UE devices. The frame structures 1 800 can be used with the systems 400, 500 and variations thereof. The frame structures 1800 are provided for illustrative purposes and as an example. It is appreciated that other suitable frame structures and variations thereof can be utilized.

[00203] The structures 1800 include a frame structure 1801 as perceived by UE1 , a frame structure 1803 as perceived by UE3 and a frame structure 1802 as

perceived/generated by a node.

[00204] The frame structure 1802 includes a control region (mPDCCH) and a data region (mPDSCH) for the UE1 . The control region for UE1 encompasses only a first portion of a control region. However, the UE1 perceives the control region as being longer as shown in the perceived frame structure for UE1 1801 .

[00205] Similarly, the frame structure 1802 includes a control region (mPDCCH) and a data region (mPDSCH) for the UE2. The control region for UE2 encompasses only a first portion and the data region encompasses a second portion as shown. However, the UE2 perceives the control region as being shorter than that of the UE1 in the perceived frame structure 1 803. The perceived frame structure 1803 also has shorter subframe durations than the structure 1801 .

[00206] Thus, the UE devices can perceive frame structures that vary from a transmitted frame structure and/or frame structures perceived by other UE devices. Each UE device can perceive frame structures having different mMTC frame

characteristics, including subframe duration, subcarrier spacings and the like.

[00207] While the methods described within this disclosure are illustrated in and described herein as a series of acts or events, it will be appreciated that the illustrated ordering of such acts or events are not to be interpreted in a limiting sense. For example, some acts may occur in different orders and/or concurrently with other acts or pre apart from those illustrated and/or described herein. In addition, not all illustrated acts may be required to implement one or more aspects or embodiments of the description herein. Further, one or more of the acts depicted herein may be carried out in one or more separate acts and/or phases.

[00208] FIG. 19 is a flow diagram illustrating a method 1900 for using a frame structure for resource allocation for mobile communication systems in accordance with some embodiments. The method 1900 facilitates meeting or providing mMTC capabilities for one or more UE devices by configuring the frame structure based on the mMTC capabilities.

[00209] The method or process 1900 is described with reference to a UE device and a node, however it is appreciated that other device and/or nodes can be used. For example, the node can be other types of nodes, such as an eNB, gNB and the like. The method 1 900 can be implemented using the above systems, arrangements and variations thereof.

[00210] The method 1900 begins at block 1902, where a node determines or obtains mMTC capabilities for one or more UE devices. The mMTC capabilities can include requirements that the UE devices need or are required to perform at. It is appreciated that the mMTC capabilities can vary from one UE to another and be UE specific. The mMTC capabilities include bandwidth capabilities, coverage, coverage levels, latency requirements/capabilities, data rates and the like for the one or more UE devices. The mMTC capabilities can also be requirements, such as requirements based on a standard.

[00211 ] In one example, the one or more UE devices are part of a cell. In another example, the one or more UE devices are a set or group of UE devices from a plurality of cells.

[00212] The node determines or assigns FTRUs for the one or more devices at block 1904 based on the mMTC capabilities for the one or more UE devices. As described above, the FTRUs are frequency-time resource units (FTRU) and are units of frequency or time. The FTRUs can be specific in terms of subcarriers, slots, and subframe lengths. The subcarrier is a frequency unit. The slots and/or subframe lengths can be specific in terms of time and/or symbols, such as OFDM symbols. The FTRUs can be assigned for each of the one or more UE devices, thus they can be UE specific. [00213] The node configures or generates a frame structure at 1906 using the assigned FTRUs and based on the mMTC capabilities for the one or more UE devices.

[00214] The frame structure is generated by arranging frequency-time slices, frequency-time slicing patterns and/or FTRUs based on mMTC frame characteristics, which include an underlying numerology, cyclic prefix (CP) length, the number of subcarriers in the frequency domain, the length or number of OFDM symbols in the time domain, the repetition level, the spreading factor in the time/frequency domain, a modulation scheme, a coding scheme, and the like. The arranging includes assigning FTRUs and/or slices to particular UE devices to match or meet mMTC capabilities. For example, addition frequency units can be assigned for a slice associated with a UE device that requires a higher bandwidth. As another example, additional time units or slots can be assigned for a slice associated with a UE device to enhance coverage.

[00215] The frame structure typically includes a control region and a data region. The control region can include a PDCCH or mPDCCH and the downlink region can include a PDSCH or mPDSCH.

[00216] The node provides the frame structure at block 1908. The frame structure can be provided by signaling the one or more UE devices, broadcasting the frame structure in an information block, and the like.

[00217] The node generates downlink data and transmits the downlink data at block 1910. The downlink data is generated in accordance with the frame structure and can include control information and/or data information within the control and data regions. In one example, baseband circuitry of the node generates that downlink data in accordance with the frame structure and provides the downlink data to RF circuitry for transmission to the one or more UE device.

[00218] The one or more UE devices receive the downlink data and decode one or more perceived frame structures at block 1912. The perceived frame structure can be the same as the node generated frame structure. Alternately, the perceived frame structure can vary.

[00219] The one or more UE devices use UE assigned or specific slices of the downlink data to obtain control and/or data information for the respective UE device.

[00220] The one or more UE device can generate an uplink transmission in accordance with the perceived frame structures at block 1914.

[00221 ] The method 1900 can be repeated and/or re-utilized for modifying the frame structure and/or enhancing mMTC operation. It is appreciated that suitable variations of the method 1900 are contemplated. [00222] Referring again to FIG. 4, the UE device 401 can be configured to perform a connection-less uplink transmission at 412. The UE device 401 supports mMTC and can perform three types of connection-less uplink transmission schemes for mMTC, as shown below.

[00223] Type 1 Autonomous Uplink Transmission scheme: for this option, an mMTC UE randomly selects one resource within a resource pool and transmit the data in the uplink on the selected resource. It is noted that Type 1 is typically suitable for relatively small packet sizes.

[00224] Type 2 Autonomous Uplink Transmission scheme: for this option, the mMTC UE randomly selects one resource within a scheduling request (SR) region in resource pool and transmits the SR information on the selected resource that contains the resource allocation for data transmission. It is noted that the SR for Type 2 scheme is more of a resource indication for the subsequent data transmission rather than a "request" to the eNodeB for an UL grant. Subsequently, the mMTC UE transmits the uplink data on the resource which is indicated in the SR information. It is noted that Type 3 is typically suitable for relatively large packet sizes.

[00225] Type 3 Partially Autonomous Uplink Transmission scheme: this option is a variant of the Type 2 connection-less scheme, wherein, similar to Type 2 scheme, the mMTC UE randomly selects a resource within the SR region and transmits the SR on the selected resource with information on the resource selected for subsequent data transmission. However, unlike the Type 2 scheme, this scheme is only partially autonomous in the sense that the MTC UE transmits on the indicated resource only if it receives an ACK, in response to its transmitted SR, granting transmission on the UL from the eNodeB. The ACK response to the SR can help reduce collisions for the actual data transmission that can be beneficial especially for medium-to-large transmitted data packet sizes in relatively heavy system loading conditions. At the same time, this mechanism can reduce the latency and signaling overhead compared to the RACH procedure currently defined for 3GPP LTE/LTE-A systems.

[00226] The UE-initiated connectionless transmission schemes can be classified either as fully-autonomous (Type-1 and Type-2) or partially autonomous (Type-3) transmission schemes. The term partially autonomous implies that an eNB or other node can influence the UE's uplink transmission following the eNB's reception of an SR from that UE.

[00227] Thus, in operation, a UE, such as the UE 401 , determines whether to transmits according to fully-autonomous access or via partially autonomous access. The determination can be based on assistance information or feedback sent by the network and the local information available at the mMTC device (e.g. estimated path loss, payload size, airtime to transmit its uplink traffic etc.). If the UE chooses to transmit in a fully-autonomous manner, a suitable or optimum resource Frequency Time Resource Unit (FTRU) resource index on which the mMTC UE should transmit on uplink is determined. This resource index, expressed in units of Frequency Time Resource Units (FTRU), conveys the location of the time-frequency resources over which the mMTC UE transmits over uplink.

[00228] Generally, fully-autonomous access can be more suitable when an estimated or anticipated airtime occupancy is small so as to minimize control signaling overhead. On the other hand, partially autonomous access can be more suitable in higher traffic loads so that the network can over-rule or assign the UE's uplink transmissions on different set of frequency resources, if needed, based on the relative uplink interference.

[00229] The feedback or assistance information is conveyed by a network and can be used at the mMTC UE device to choose its transmission scheme over uplink. The assistance information broadcasted by the network is in the form of:

[00230] Buffer size thresholds

[00231 ] Airtime occupancy thresholds

[00232] Loading condition (e.g. Measured Uplink Channel Quality, Measured Uplink Interference, Uplink Resource Utilization) which is used by the UE to make a

determination of the airtime occupancy of its uplink transmission.

[00233] For modeling UL transmission, given the limited payload size and the opportunistic type of transmission, a simple model is used: we assume that the UE transmits over a single Frequency-Time Resource Unit (FTRU) j, denoted by FTRU-j.

[00234] In absence of eNB driven feedback, the UE generally cannot determine its uplink SINR for two reasons: first, the UE only has statistical knowledge of its serving channel gain, based on DL path loss measurement, which corresponds to E[G,].

Second, the UE cannot estimate its uplink interference and hence cannot compute its uplink SINR/spectral efficiency used for airtime derivation.

[00235] Parameters of interest are described below.

[00236] Resource Frequency-Time Resource Unit (FTRU) over which mMTC device UL transmission occurs

[00237] /FTRU Configured FTRU resources at UE of interest.

[00238] N_sb Number of sub-bands across entire system bandwidth

[00239] Nscsb Number of sub-carriers per sub-band [00240] Ntonej Number of tones corresponding to FTRU-j

[00241 ] P_Cimax Maximum UE transmission power (per device capability) in linear scale (Watts)

[00242] Tj Time duration of FTRU-j

[00243] SCS Subcarrier spacing (in Hz)

[00244] UCSINR [n] Network feedback on Uplink Channel SINR for sub-band n

[00245] UINF [n] Network feedback on Uplink Interference for sub-band n

[00246] iV_data Uplink queue size (in bits) at UE of interest.

[00247] 4T_thresh Air-time threshold broadcasted from the network

[00248] Network feedback schemes, methods or approaches are performed by a UE device to estimate airtime for hypothetical autonomous transmission on FTRU.

[00249] In one example, an eNB, provides UE dedicated signaling of a sub-band specific uplink channel quality measurement using a metric, where the metric is a function of an uplink signal to noise ratio (SINR). It is appreciated that other nodes can be used instead of the eNB.

[00250] The feedback can be provided using a number of suitable mechanisms.

[00251 ] In one example, the feedback is provided using UE-dedicated RRC signaling.

[00252] In another example, the feedback is provided using MAC-CE signaling.

[00253] In another example, the feedback is provided with an ACK response to the UE's Scheduling Request in Type 3 UL transmission.

[00254] The SINR based feedback metric allows the node to provide fine-grained feedback (on a per sub-band basis) accounting for the frequency selective channel variations or the time-domain channel variations of the channel between the UE and its serving eNB.

[00255] FIG. 20 is a diagram that illustrates an example of SINR based feedback 2000 in accordance with some embodiments.

[00256] The feedback 2000 shows an association between 0 to Nsb-1 sub-band indexes and Nsc, sb subcarriers. Uplink channel quality can be reported on a set of sub-bands where the sub-band size is chosen so that the UE transmits with suitable transmission power if using that sub-band.

[00257] Assume the system bandwidth is partitioned into N_sb sub-bands and N_{sc sb} number of sub-carriers per sub-band. For purposes of channel feedback, the eNB assumes a hypothetical UE transmission on a single sub-band within the set

(0, 1, ... , N_sb - 1}. The sub-band size is assumed to be such that the UE would be power limited (i.e. transmits with maximum transmission power according to device capability) when transmitting over this bandwidth.

[00258] The uplink channel quality feedback value on sub-band n denoted as

UCSINR [n] is a quantized version of the estimate uplink SINR on n th sub-band, i.e. eSINR_est[n].

[00259] Assuming a quantization function Q(.), the quantity UCSINR[n] on sub-band n is given as

[00260] UCSINR[n] = Q(eSINR_est [n]), 0 < n < N_sb - 1 (Eq. 1 )

[00261 ] Wideband uplink quality feedback is a special case obtained by setting N_sb = 1 and setting N_{sc sb} to equal the total number of useful sub-carriers across the entire bandwidth.

[00262] FIG. 21 is a table 2100 illustrating an example SINR quantization function in accordance with some embodiments.

[00263] The table 2100 includes indexes values and corresponding SINR levels.

[00264] The network driven SINR feedback would be in the form of a set of tuples \ i{(SBi, UCSINR [i])} where each pair consists of the sub-band index chosen from within (0, 1, ... , N_sb - 1} and a corresponding uplink channel quality (SINR) level on that sub- band.

[00265] The term eSINR_est[n] denotes the averaged SINR on sub-band n derived as

[00266] eS,NR_e n] <^■¾ ²>

[00267] The function /(.) designates an information measure function, Γ¹ (. ) denotes its inverse and a^resp. a₂) are scaling parameters. The eNB's estimated SINR on sub-

P xGlk]

carrier k namely SINR_est [k] , equals— — -¹— where G[k] denotes the (estimated)

^Nsc,sb XlNFestlk]

serving cell channel gain on sub-carrier k. The term INF_est[k] = σ_¾ (1 + IOT_{est intra}[k] + 10Test,inter \) denotes the eNB's estimate of the average uplink interference on sub- carrier k, comprising of the sum of the intra-cell (due to contention) and inter-cell interference. Note that for computation simplicity, the estimated interference on each sub-carrier within sub-band k could be chosen as the average interference across the sub-band containing k.

[00268] The network feedback on a per sub-band basis may not be aligned with the

UE's transmission granularity (in Frequency Time Resource Units). For example, the eNB can provide feedback on a per PRB basis (assuming 1 sub-band corresponds to

12 sub-carriers) whereas the UE may desire to transmit on fewer than 12 sub-carriers thfirfihv mnnentrating its maximum transmit power on fewer sub-c^arrif3r<^ [00269] FIG. 22 is a diagram illustrating an example of an eNB providing network feedback 2200 on a PRB basis.

[00270] Also, it is noted that the FTRU boundaries may not be aligned with the sub- band boundaries. For accurate SINR estimation, the UE can re-scale the network's SINR feedback to reflect the actual transmission PSD on uplink while transmitting on its FTRU.

[00271 ] For example, if the UE intends to transmit on FTRU-j which partially overlaps with sub-bands q and q+1 for which network feedback is available. The UE can derive an effective SINR given as:

[00272] SINR_eff = β x UCSINR [q] + (1 - /?) x UCSINR[q + 1] (Eq. 3)

[00273] where the weight β can be the ratio of the number of sub-carriers of FTRU-j contained within sub-band q. This effective SINR is then used to derive the uplink SINR SLNR_j on FTRU-j from the following equation assuming open-loop power control:

.ix{P_n0vn+axPL_∞t-3o)

*sc,sb

> P ¹ cc,, m...a_x

tone,]

[00274] SINR_j = (Eq. 4)

x ^Nsc,sb x otherwise

c, 12

[00275] Thus, the above equations and discussion provide a mechanism for the eNB to provide UE specific SINR feedback.

[00276] In another mechanism, the eNB broadcasts a different metric, corresponding to the average estimated interference plus noise on a per sub-band basis. This feedback relies on broadcast, rather than unicast, so the signaling overhead is typically smaller. However, this mechanism or method does not account for time-domain variation and frequency selectivity of the channel between the UE and its serving eNB.

[00277] The eNB is assumed to average the interference to yield one value per sub- band. The eNB then feeds back to the UE, an uplink interference metric UINF[n] on sub-band n based on a quantized version of the estimated averaged interference.

[00278] The uplink interference feedback value on sub-band n denoted as UINF[n] is expressed as a quantized estimate of the averaged uplink interference eINF_est [n] on that sub-band.

[00279] Assuming a quantization function Q(.), the quantity UINF[n] on sub-band n is given as

[00280] UINF[n] = Q(eINF_est[n] (Eq. 5)

[00281 ] The argument to the quantization function eINF_est [n] denotes the eNB's estimate of the average interference level per sub-carrier on sub-band n, expressible as [00282] eINF_est [n] = [k] + IOT_est,_inter[k]) (Eq.

6)

[00283] Wideband uplink interference feedback is a special case, obtained by setting N_sb = 1 and setting N_{sc sb} to equal the total number of useful sub-carriers across the entire bandwidth.

[00284] As an example, the eNB may feedback uplink interference level 1 <= I <= 4 quantized to 4 different levels.

[00285] FIG. 23 is a table 2300 depicting suitable uplink interference level in accordance with some embodiments.

[00286] The eNB provides the feedback quantized to 4 different levels as shown in the table 2300.

[00287] The network driven interference feedback would be in the form of a set of tuples \ i{(SBi, UINF[i])} where each pair consists of the sub-band index chosen from within (0, 1, ... , N_sb - 1} and a corresponding measured uplink interference level on that sub-band.

[00288] As an alternative to receiving feedback from the eNB, the UE can estimate FTRU SINR using uplink interference feedback.

[00289] The UE estimates an effective interference lNF_eff on FTRU-j which can be obtained as a weighted average across the sub-bands straddling FTRU-j. Based on the effective interference lNF_eff , the UE derives its SINR for a hypothetical transmission on FTRU-j, given as

^~PL∞ JV_{tone j} xl0^{o lx}(^pnom+axi'½st-³⁰)

INF_eff ' 12 > Pc^c'. ^max ^

[00290] SINRj =

₁₀o.ix(P_nom-(i-a)xPL_est-3o)

otherwise

12x/JVF_e//

[00291 ] where we assume that the path loss is estimated by each UE individually using the RSRP measurements.

[00292] Given a UE estimated SINR denoted as SINRj across FTRU-j, the UE estimates its uplink spectral efficiency (assuming a Gap Γ from Shannon) given as:

[00293] SEj = log₂ (l + (units: bps/Hz) (Eq. 8)

[00294] The corresponding achievable uplink data rate when transmitting on FTRU-j correspondingly equals N_{tone j} x SCS x SEj . Given a time occupancy 7) for FTRU-j, the minimum number of FTRU NFTFtu required to flush the UE's uplink queue is given as ^Ndata

[00295] JV| FTRU, j (Eq. 9)

TjXN_tone XSCSx SEj

[00296] Thus, the estimated air time ATj at the UE for transmitting its payload therefore equals

[00297] ATj = Tj x N_FTRU (Eq. 1 0)

[00298] Furthermore, the 5G mMTC UE can utilize pre-determined modulation and coding scheme to characterize the required air time for the uplink transmission.

[00299] It is noted that the estimated airtime is (approximately) independent of the FTRU duration 7} and is minimized by choosing the FTRU resource j which maximizes

Ntone X SEj .

[00300] The denominator of the airtime expression equals Ntone_j ^x l°g₂ (l + — -²)- If the UE is power limited, the latter quantity in this product is a logarithmic (concave) function of l/N_{Xone j} . This suggests that if the UE experiences good radio quality i.e. SINRj » 1, the suitable or optimal FTRU (in terms of minimizing air time) chosen for uplink transmission has the largest possible N_tone,r

[00301 ] For choosing the FTRU over which its uplink transmissions occur the UE can do so by:

[00302] Scheme 1 : UE chooses index j from within /FTRU uniformly randomly and then computes the airtime per the steps described above.

[00303] Scheme 2: UE chooses index j from /FTRU iⁿ order to minimize the estimated air time. The corresponding estimated air time Al given as

[00304] ; = arg min₇-_e/FTRU ATj = arg max_;e;FTRU JV_tone,₇- x SEj (Eq. 1 1 )

[00305] Fig. 24 is a flow diagram illustrating a method 2400 of performing uplink transmissions in accordance with some embodiments. The method 2400 can be used and/or performed with the systems 1 00, 400, 500 and variations thereof. It is appreciated that suitable variations thereof are contemplated.

[00306] The method can be performed by a UE device, such as the UE device 401 .

Additionally, the UE supports mMTC, in this example.

[00307] The method 2400 begins at block 2402, where the mMTC UE wakes up upon receiving U L traffic.

[00308] The mMTC UE performs DL synchronization at block 2404 followed by reading a MIB and a SIB. The SI B can potentially carry the UL interference feedback for a set of sub-bands. The UE determines or obtains an UL interference metric. In one example, the feedback or assistance information is provided in the MIB or SIB. However, it is appreciated that other suitable techniques can be used to obtain the feedback or assistance information.

[00309] If UL interference metric is above a threshold at block 2406 (broadcasted by SIB), the mMTC UE can perform a random backoff at block 2414. The UL interference metric can be defined as a function of UL interference per sub-bands. For instance, we can define the uplink interference metric as: min_n eINF_est [n] . Note that the uplink interference might be due to the contention-based access of intra-cell mMTC UEs or possibly due to the inter-cell interference.

[00310] If the UL interference metric is below the threshold, then the mMTC UE can characterize the air time (AT) for a first transmission based on the broadcasted UL interference feedback at block 2408. Furthermore, the network may also provide uplink channel quality feedback to the UE. This could be in the form of UE-dedicated signaling of the uplink channel quality information (proxy for uplink SINR) on a set of sub-bands. For the consecutive transmissions, the mMTC UE may utilize this information to estimate the air time.

[00311 ] The air time (AT), also referred to as an air time estimation, is an estimate of uplink transmission time for the UE to transmit its data.

[00312] The mMTC UE will then compare the estimated air time against network broadcasts airtime thresholds at block 241 0 to determine whether to transmit using fully- autonomous or partially autonomous transmission.

[00313] If the estimated air time, i.e. AJ , falls below the broadcasted air time threshold 4T_thresh , the UE transmits according to a fully-autonomous scheme (e.g. Type 1 or Type 2) at block 241 6.

[00314] Otherwise, the UE transmits according to a partially-autonomous scheme (e.g. Type 3) at block 241 2.

[00315] For the case, where the mMTC UE selects transmission type 1 (or 2), if the number of retransmission exceeds a threshold at block 2422, then the mMTC UE switches the transmission type 3 at the block 241 2.

[00316] It is appreciated that suitable variations of the method 2400 are contemplated. Further, it is appreciated that blocks can be omitted and/or additional blocks performed.

[00317] In the proposed algorithm, the mMTC device autonomously selects the U L transmission type based on the estimated air time and broadcasted thresholds by the network. However, the network and the UE need to have a consistent understanding of the type of uplink transmission, regardless of fully-autonomous (Type 1 or Type 2) or partially autonomous (Type 3) uplink. [00318] To be specific, consider the case with Type 2 and Type 3 uplink transmission. Note that in both these types, the UE transmits an SR, containing time-frequency resources, conveying its intent to transmit on uplink over these resources. Upon receiving SR, to determine whether or not to respond to the SR request, the network requires to determine whether the mMTC device's transmissions fall under Type 2 or Type 3.

[00319] For instance, if the SR corresponds to the transmission Type 3, the UE expects to receive from the eNB an A/N response and possibly any modified uplink resource assignment. However, a UE transmitting using Type 2 expects no A/N response from the eNB in response to its SR transmission; instead it expects that the eNodeB would decode the UL mPUSCH on the time-frequency resources indicated via its SR.

[00320] Some examples of suitable mechanisms to differentiate between type 1 and type 2 transmissions are provided.

[00321 ] A SR transmitted by a UE at the beginning of its uplink transmission carries the transmission type information (i.e. Type 2 or Type 3), in addition to the time- frequency resource assignments for the mPUSCH transmission. For instance, a one bit indicator in the SR can be used to differentiate whether Type 2 or 3 mPUSCH is transmitted.

[00322] Different SR regions can be broadcasted through a SIB message by an eNB or node to differentiate different uplink transmission types, e.g., Type 2 and Type 3 transmissions.

[00323] Two different sets (one set for Type 2 and other for Type 3) of uplink DM-RS parameters (base sequence, cyclic shift, OCC) are configured for SR transmission. The eNB can detect whether the UE transmits according to Type 2 or Type 3 by determining the corresponding UL DM-RS parameters used within the UE's SR transmission.

[00324] In another mechanism, a SR can contain both sequence and message - specifically, prior to a Type 3 transmission, a mPRACH would be transmitted prior to the SR message, where the SR message carries mMTC device ID and resource allocation for mPUSCH. The eNB can detect the presence or absence of the mPRACH to disambiguate whether the UE's UL transmission corresponds to Type 2 or Type 3.

[00325] Furthermore, an eNB can be configured to resolve the disambiguation between Type 1 and Type2/3. For instance, the eNB can differentiate the data transmission of Type 1 from SR transmission of Type 2/3. However, the differentiation between Type 1 and Type 2/3 at eNB is generally simpler, as Type 1 does not require SR. The eNB can utilize the following mechanism for differentiation:

[00326] If there is no SR prior to the mPUSCH transmission, the transmission is indicated as Type 1 .

[00327] Alternatively, different LCIDs can be utilized to differentiate the MAC SDU of Type 1 from Type 2/3. Furthermore, new MAC control element can be introduced to differentiate Type 1 from Type 2/3.

[00328] Different regions for mPUSCH transmission Type 1 , Type 2 and Type 3, where different regions can be multiplexed in either TDM, FDM manner or a

combination of both.

[00329] In autonomous UL transmission, the scheduling request and scheduling grant by DCI do not exist. Therefore, the network can configure different RNTIs for different transmission Types and broadcast them in the SIB message. Consequently, the mMTC UE device can utilize the broadcasted RNTI in the scrambling seed generation for to indicate the transmission type.

[00330] Another proposed mechanism is to use different CRC mask to differentiate different transmission types.

[00331 ] Similarly, the network can broadcast different mPUSCH DMRS

configurations, such as base sequences, cyclic shifts, OCCs for different transmission types.

[00332] As used herein, the term "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, 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 the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

[00333] As it employed in the subject specification, the term "processor" can refer to substantially any computing processing unit or device including, but not limited to including, single-core processors; single-processors with software multithread execution capability; multi-core processors; multi-core processors with software multithread execution capability; multi-core processors with hardware multithread technology;

parallel platforms; and parallel platforms with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application specific integrated circuit, a digital signal processor, a field programmable gate array, a programmable logic controller, a complex programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions and/or processes described herein. Processors can exploit nano-scale architectures such as, but not limited to, molecular and quantum-dot based transistors, switches and gates, in order to optimize space usage or enhance performance of mobile devices. A processor may also be implemented as a combination of computing processing units.

[00334] In the subject specification, terms such as "store," "data store," data storage," "database," and substantially any other information storage component relevant to operation and functionality of a component and/or process, refer to "memory

components," or entities embodied in a "memory," or components including the memory. It is noted that the memory components described herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory.

[00335] By way of illustration, and not limitation, nonvolatile memory, for example, can be included in a memory, non-volatile memory (see below), disk storage (see below), and memory storage (see below). Further, nonvolatile memory can be included in read only memory, programmable read only memory, electrically programmable read only memory, electrically erasable programmable read only memory, or flash memory.

Volatile memory can include random access memory, which acts as external cache memory. By way of illustration and not limitation, random access memory is available in many forms such as synchronous random access memory, dynamic random access memory, synchronous dynamic random access memory, double data rate synchronous dynamic random access memory, enhanced synchronous dynamic random access memory, Synchlink dynamic random access memory, and direct Rambus random access memory. Additionally, the disclosed memory components of systems or methods herein are intended to include, without being limited to including, these and any other suitable types of memory.

[00336] Examples can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including instructions that, when performed by a machine cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to embodiments and examples described herein. [00337] Example 1 is an apparatus configured to be employed within a base station. The apparatus comprises baseband circuitry which includes a radio frequency (RF) interface and one or more processors. The one or more processors are configured to obtain massive machine type communications (mMTC) capabilities for a user equipment (UE) device, wherein the mMTC capabilities include coverage, bandwidth and latency. The one or more processors are further configured to assign frequency- time resource units (FTRU) for the UE device according to the mMTC capabilities; generate a frame structure based on the assigned FTRU and the mMTC capabilities; generate downlink data using the generated frame structure; and provide the downlink data to the RF interface for transmission to the UE device.

[00338] Example 2 includes the subject matter of Example 1 , including or omitting optional elements, where the base station is one of a next Generation NodeB and an evolved Node B.

[00339] Example 3 includes the subject matter of any of Examples 1 -2, including or omitting optional elements, where the one or more processors are configured to assign a number of subcarriers of the FTRU for the UE device based on the bandwidth specified in the mMTC capabilities.

[00340] Example 4 includes the subject matter of any of Examples 1 -3, including or omitting optional elements, where the one or more processors are configured to assign a number of slots based on a quality of service (QoS) specified in the mMTC

capabilities.

[00341 ] Example 5 includes the subject matter of any of Examples 1 -4, including or omitting optional elements, where the one or more processors are configured to assign a subframe length for control and data regions of the frame structure based on the mMTC capabilities.

[00342] Example 6 includes the subject matter of any of Examples 1 -5, including or omitting optional elements, where the one or more processors are configured to generate frequency-time slicing patterns of the frame structure for the UE device based on the mMTC capabilities to generate the frame structure.

[00343] Example 7 includes the subject matter of any of Examples 1 -6, including or omitting optional elements, where the one or more processors are configured to include inter-frame and/or intra frame repetition in the frame structure.

[00344] Example 8 includes the subject matter of any of Examples 1 -7, including or omitting optional elements, where wherein the one or more processors are configured to assign second FTRUs for a second UE device having second mMTC capabilities, wherein the second mMTC capabilities are at least partially different than the mMTC capabilities for the UE device and wherein the one or more processors are configured to include the second FTRUs in the generated frame structure.

[00345] Example 9 includes the subject matter of any of Examples 1 -8, including or omitting optional elements, where the one or more processors are configured to generate an uplink frame structure based on the assigned FTRUs.

[00346] Example 10 is an apparatus configured to be employed within a user equipment (UE) device comprising baseband circuitry. The baseband circuitry includes a radio frequency (RF) interface and one or more processors. The one or more processors are configured to obtain massive machine type communications (mMTC) capabilities for the UE device, wherein the mMTC capabilities include coverage, bandwidth and latency; obtain a frame structure based on the mMTC capabilities; obtain downlink data via the RF interface from a node; and decode the downlink data according to the obtained frame structure.

[00347] Example 1 1 includes the subject matter of Example 10, including or omitting optional elements, where the frame structure includes a control region having a length based on the latency of the mMTC capabilities.

[00348] Example 12 includes the subject matter of any of Examples 10-1 1 , including or omitting optional elements, where the frame structure includes a first subframe length for the UE device and a second subframe length for a second UE device.

[00349] Example 13 is one or more computer-readable media having instructions that, when executed, cause a base station to assign frequency-time resource units (FTRUs) for one or more UE devices of a cell according to capabilities of the one or more UE devices, wherein the capabilities include bandwidth, coverage and latency; and generate a frame structure for the one or more UE devices of the cell using the assigned FTRUs.

[00350] Example 14 includes the subject matter of Example 13, including or omitting optional elements, where the frame structure includes a fixed length for a control region of the subframe.

[00351 ] Example 15 includes the subject matter of any of Examples 13-14, including or omitting optional elements, where the frame structure includes a physical downlink control channel (PDCCH) and a physical downlink shared channel (PDSCH).

[00352] Example 16 is an apparatus configured to be employed within a user equipment (UE) device. The apparatus includes a means to provide latency, coverage and bandwidth capabilities for the UE device and a means to perceive a downlink frame structure based on the provided latency, coverage and bandwidth capabilities, wherein the downlink frame structure includes subcarrier spacing based on the bandwidth capabilities and a control region length based on the latency.

[00353] Example 17 includes the subject matter of Example 16, including or omitting optional elements, further comprising a means to receive downlink data and decode the downlink data using the perceived downlink frame structure.

[00354] Example 18 includes the subject matter of any of Examples 16-17, including or omitting optional elements, where the perceived downlink frame structure is different than an actual downlink frame structure.

[00355] Example 19 is an apparatus configured to be employed within a base station. The apparatus comprises baseband circuitry which includes a radio frequency (RF) interface and one or more processors. The one or more processors are configured to obtain massive machine type communications (mMTC) capabilities for a user equipment (UE) device, wherein the mMTC capabilities include coverage, bandwidth and latency. The one or more processors are further configured to receive network feedback via the RF interface, wherein the network feedback includes assistance information; determine uplink interference based at least partially on the received network feedback; estimate air time based at least partially on the determined uplink interference; and select a massive machine type communications (mMTC)

transmission type based on the estimated air time for an uplink transmission.

[00356] Example 20 includes the subject matter of Example 19, including or omitting optional elements, where the one or more processors are configured to generate uplink data for transmission and provide the uplink data to the RF interface for transmission using the selected mMTC transmission scheme.

[00357] Example 21 includes the subject matter of any of Examples 19-20, including or omitting optional elements, where the mMTC transmission type is fully autonomous.

[00358] Example 22 includes the subject matter of any of Examples 19-21 , including or omitting optional elements, where the mMTC transmission type is partially autonomous.

[00359] Example 23 is an apparatus configured to be employed within a user equipment (UE) device comprising baseband circuitry. The baseband circuitry includes a radio frequency (RF) interface and one or more processors. The one or more processors are configured to generate uplink assistance information for a user equipment (UE) device, where the uplink assistance information includes buffer size thresholds, airtime occupancy thresholds, and loading conditions; generate feedback based on the uplink assistance information; and provide the feedback to the RF interface for transmission to the UE device.

[00360] Example 24 includes the subject matter of Example 23, including or omitting optional elements, where the feedback is provided as a sub-band specific uplink channel quality measurement on a UE dedicated signaling and/or as a broadcasted metric that corresponds to an average estimated interference plus noise on a per sub- band basis.

[00361 ] Example 25 includes the subject matter of any of Examples 23-24, including or omitting optional elements, where the loading conditions include one or more of a measured uplink channel quality, measured uplink interference, uplink resource utilization and wherein the loading condition is used by the UE to determine an airtime occupancy of an uplink transmission.

[00362] It is to be understood that aspects described herein can be implemented by hardware, software, firmware, or any combination thereof. When implemented in software, functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media or a computer readable storage device can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD- ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or other tangible and/or non-transitory medium, that can be used to carry or store desired information or executable instructions. Also, any connection is properly termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

Combinations of the above should also be included within the scope of computer- readable media.

[00363] Various illustrative logics, logical blocks, modules, and circuits described in connection with aspects disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other

programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform functions described herein. A general-purpose processor can be a microprocessor, but, in the alternative, processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Additionally, at least one processor can comprise one or more modules operable to perform one or more of the s and/or actions described herein.

[00364] For a software implementation, techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform functions described herein. Software codes can be stored in memory units and executed by processors. Memory unit can be implemented within processor or external to processor, in which case memory unit can be communicatively coupled to processor through various means as is known in the art. Further, at least one processor can include one or more modules operable to perform functions described herein.

[00365] Techniques described herein can be used for various wireless communication systems such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other systems. The terms "system" and "network" are often used interchangeably. A CDMA system can implement a radio technology such as Universal Terrestrial Radio Access (UTRA), CDMA1800, etc. UTRA includes Wideband-CDMA (W-CDMA) and other variants of CDMA. Further, CDMA1800 covers IS-1800, IS-95 and IS-856 standards. A TDMA system can implement a radio technology such as Global System for Mobile

Communications (GSM). An OFDMA system can implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.1 1 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.18, Flash-OFDML , etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) is a release of UMTS that uses E-UTRA, which employs OFDMA on downlink and SC-FDMA on uplink. UTRA, E-UTRA, UMTS, LTE and GSM are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). Additionally, CDMA1 800 and UMB are described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2). Further, such wireless communication systems can additionally include peer-to-peer (e.g., mobile-to-mobile) ad hoc network systems often using unpaired unlicensed spectrums, 802. xx wireless LAN, BLUETOOTH and any other short- or long- range, wireless communication techniques.

[00366] Single carrier frequency division multiple access (SC-FDMA), which utilizes single carrier modulation and frequency domain equalization is a technique that can be utilized with the disclosed aspects. SC-FDMA has similar performance and essentially a similar overall complexity as those of OFDMA system. SC-FDMA signal has lower peak-to-average power ratio (PAPR) because of its inherent single carrier structure. SC-FDMA can be utilized in uplink communications where lower PAPR can benefit a mobile terminal in terms of transmit power efficiency.

[00367] Moreover, various aspects or features described herein can be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer-readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips, etc.), optical disks (e.g., compact disk (CD), digital versatile disk (DVD), etc.), smart cards, and flash memory devices (e.g., EPROM, card, stick, key drive, etc.). Additionally, various storage media described herein can represent one or more devices and/or other machine-readable media for storing information. The term "machine-readable medium" can include, without being limited to, wireless channels and various other media capable of storing, containing, and/or carrying instruction(s) and/or data. Additionally, a computer program product can include a computer readable medium having one or more instructions or codes operable to cause a computer to perform functions described herein.

[00368] Communications media embody computer-readable instructions, data structures, program modules or other structured or unstructured data in a data signal such as a modulated data signal, e.g., a carrier wave or other transport mechanism, and includes any information delivery or transport media. The term "modulated data signal" or signals refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in one or more signals. By way of example, and not limitation, communication media include wired media, such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. [00369] Further, the actions of a method or algorithm described in connection with aspects disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or a combination thereof. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium can be coupled to processor, such that processor can read information from, and write information to, storage medium. In the alternative, storage medium can be integral to processor. Further, in some aspects, processor and storage medium can reside in an ASIC. Additionally, ASIC can reside in a user terminal. In the alternative, processor and storage medium can reside as discrete components in a user terminal. Additionally, in some aspects, the s and/or actions of a method or algorithm can reside as one or any combination or set of codes and/or instructions on a machine-readable medium and/or computer readable medium, which can be incorporated into a computer program product.

[00370] The above description of illustrated embodiments of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. While specific embodiments and examples are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such embodiments and examples, as those skilled in the relevant art can recognize.

[00371 ] In this regard, while the disclosed subject matter has been described in connection with various embodiments and corresponding Figures, where applicable, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same, similar, alternative, or substitute function of the disclosed subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but rather should be construed in breadth and scope in accordance with the appended claims below.

[00372] In particular regard to the various functions performed by the above described components (assemblies, devices, circuits, systems, etc.), the terms (including a reference to a "means") used to describe such components are intended to correspond, unless otherwise indicated, to any component or structure which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations of the disclosure. In addition, while a particular feature may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.

Claims

CLAIMS What is claimed is:

1 . An apparatus for a base station, comprising baseband circuitry having:

a radio frequency (RF) interface; and

one or more processors configured to:

obtain massive machine type communications (mMTC) capabilities for a user equipment (UE) device, wherein the mMTC capabilities include coverage, bandwidth and latency;

assign frequency-time resource units (FTRUs) for the UE device according to the mMTC capabilities;

generate a frame structure based on the assigned FTRU and the mMTC capabilities; and

generate downlink data using the generated frame structure; and provide the downlink data to the RF interface for transmission to the UE device.

2. The apparatus of claim 1 , wherein the base station is one of a next Generation NodeB or an evolved Node B.

3. The apparatus of claim 1 , wherein the one or more processors are configured to assign a number of subcarriers of the FTRU for the UE device based on the bandwidth specified in the mMTC capabilities.

4. The apparatus of claim 1 , wherein the one or more processors are configured to assign a number of slots based on a quality of service (QoS) specified in the mMTC capabilities.

5. The apparatus of any one of claims 1 -4, wherein the one or more processors are configured to assign a subframe length for control and data regions of the frame structure based on the mMTC capabilities.

6. The apparatus of any one of claims 1 -4, wherein the one or more processors are configured to generate frequency-time slicing patterns of the frame structure for the UE device based on the mMTC capabilities to generate the frame structure.

7. The apparatus of any one of claims 1 -4, wherein the one or more processors are configured to include inter-frame and/or intra frame repetition in the frame structure.

8. The apparatus any one of claims 1 -4, wherein the one or more processors are configured to assign second FTRUs for a second UE device having second mMTC capabilities, wherein the second mMTC capabilities are at least partially different than the mMTC capabilities for the UE device and wherein the one or more processors are configured to include the second FTRUs in the generated frame structure.

9. The apparatus of any one of claims 1 -4, wherein the one or more processors are configured to generate an uplink frame structure based on the assigned FTRUs.

10. An apparatus for user equipment (UE) device, comprising baseband circuitry having:

a radio frequency (RF) interface; and

one or more processors configured to:

obtain massive machine type communications (mMTC) capabilities for the UE device, wherein the mMTC capabilities include coverage, bandwidth and latency;

obtain a frame structure based on the mMTC capabilities;

obtain downlink data via the RF interface from a node; and decode the downlink data according to the obtained frame structure.

1 1 . The apparatus of claim 10, wherein the frame structure includes a control region having a length based on the latency of the mMTC capabilities.

12. The apparatus of any one of claims 10-1 1 , wherein the frame structure includes a first subframe length for the UE device and a second subframe length for a second UE device.

13. One or more computer-readable media having instructions that, when executed, cause a base station to:

assign frequency-time resource units (FTRUs) for one or more UE devices of a cell according to capabilities of the one or more UE devices, wherein the capabilities include bandwidth, coverage and latency; and

generate a frame structure for the one or more UE devices of the cell using the assigned FTRUs.

14. The computer-readable media of claim 13, wherein the frame structure includes a fixed length for a control region of the subframe.

15. The computer-readable media of claim 13, wherein the frame structure includes a physical downlink control channel (PDCCH) and a physical downlink shared channel (PDSCH).

16. An apparatus for a user equipment (UE) device comprising:

a means to provide latency, coverage and bandwidth capabilities for the UE device; and

a means to perceive a downlink frame structure based on the provided latency, coverage and bandwidth capabilities, wherein the downlink frame structure includes subcarrier spacing based on the bandwidth capabilities and a control region length based on the latency.

17. The apparatus of claim 16, further comprising a means to receive downlink data and decode the downlink data using the perceived downlink frame structure.

18. The apparatus of any one of claims 16-17, wherein the perceived downlink frame structure is different than an actual downlink frame structure.

19. An apparatus for user equipment (UE) device, comprising baseband circuitry having:

a radio frequency (RF) interface; and

one or more processors configured to:

receive network feedback via the RF interface, wherein the network feedback includes assistance information;

determine uplink interference based at least partially on the received network feedback;

estimate air time based at least partially on the determined uplink interference;

select a massive machine type communications (mMTC) transmission type based on the estimated air time for an uplink transmission.

20. The apparatus of claim 19, wherein the one or more processors are configured to generate uplink data for transmission and provide the uplink data to the RF interface for transmission using the selected mMTC transmission scheme.

21 . The apparatus of any one of claims 19-20, wherein the mMTC transmission type is fully autonomous.

22. The apparatus of any one of claims 19-20, wherein the mMTC transmission type is partially autonomous.

23. An apparatus for node, comprising baseband circuitry having:

a radio frequency (RF) interface; and

one or more processors configured to:

generate uplink assistance information for a user equipment (UE) device, where the uplink assistance information includes buffer size thresholds, airtime occupancy thresholds, and loading conditions;

generate feedback based on the uplink assistance information; and provide the feedback to the RF interface for transmission to the UE device.

24. The apparatus of claim 23, wherein the feedback is provided as a sub-band specific uplink channel quality measurement on a UE dedicated signaling and/or as a broadcasted metric that corresponds to an average estimated interference plus noise on a per sub-band basis.

25. The apparatus of any one of claims 23-24, wherein the loading conditions include one or more of a measured uplink channel quality, measured uplink interference, uplink resource utilization and wherein the loading condition is used by the UE to determine an airtime occupancy of an uplink transmission.