WO2018212765A1

WO2018212765A1 - Overlay narrow-band internet of things evolved node b

Info

Publication number: WO2018212765A1
Application number: PCT/US2017/032925
Authority: WO
Inventors: Anand Bedekar; Rajeev Agrawal
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2017-05-16
Filing date: 2017-05-16
Publication date: 2018-11-22

Abstract

Various communication systems may benefit from overlay of capabilities. For example, certain wireless communication systems may benefit from the introduction of narrow-band (NB) internet-of-things (IoT) capabilities in the radio area network (RAN) as an overlay solution. A method can include receiving downlink data corresponding to a narrow-band internet-of-things carrier. The method can also include conditionally multiplexing the downlink data to at least one physical resource block together with other data.

Description

TITLE:

Overlay Narrow-band Internet of Things Evolved Node B

BACKGROUND:

Field:

[0001] Various communication systems may benefit from overlay of capabilities. For example, certain wireless communication systems may benefit from the introduction of narrow-band (NB) internet-of-things (IOT) capabilities in the radio area network (RAN) as an overlay solution.

Description of the Related Art:

[0002] NB-IOT has been introduced in release 13 (Rel 13) of long term evolution (LTE) as a new set of capabilities for LTE to support large numbers of IOT devices with high coverage and low battery consumption. LTE-M (LTE-Category Ml or enhanced Machine Type Communication (eMTC) or massive Machine Type Communication (mMTC) are also generally included within the category of narrow-band internet of things. Thus, the terms "narrow-band internet of things or NB-IOT" can refer to any of NB-IOT, LTE-M, LTE-Cat-Ml, or eMTC or mMTC.

[0003] An NB-IOT carrier conventionally occupies the equivalent of one LTE physical resource block (PRB). Moreover, an NB-IOT can be operated either in-band with LTE, or in an LTE guard-band, or in a standalone band, for example a re-farmed global system for mobile communication (GSM) carrier. Similarly an LTE-M or LTE-Cat Ml carrier conventionally occupies the equivalent of 6 LTE PRBs, with the possibility of using additional groups of 6 LTE PRBs as needed.

[0004] Conventional implementation permits in-band LTE operation of NB- IOT only by having a conventional LTE eNB also support the capability of NB-IOT.

SUMMARY: [0005] According to certain embodiments, a method can include receiving downlink data corresponding to a narrow-band internet-of-things carrier. The method can also include conditionally multiplexing the downlink data to at least one physical resource block together with other data. The other data can include data unrelated to narrow-band internet-of-things. The method can further include transmitting the multiplexed data.

[0006] In certain embodiments, a method can include preparing downlink data to be transmitted on a narrow-band internet-of-things carrier. The method can also include providing with the downlink data an indicator indicating at least one of a time or frequency resource where the downlink data is to be transmitted multiplexed with other data.

[0007] An apparatus, according to certain embodiments, can include means for receiving downlink data corresponding to a narrow-band internet-of-things carrier. The apparatus can also include means for conditionally multiplexing the downlink data to at least one physical resource block together with other data. The other data can include data unrelated to narrow-band internet-of- things. The apparatus can further include means for transmitting the multiplexed data.

[0008] An apparatus, in certain embodiments, can include means for preparing downlink data to be transmitted on a narrow-band internet-of-things carrier. The apparatus can also include means for providing with the downlink data an indicator indicating at least one of a time or frequency resource where the downlink data is to be transmitted multiplexed with other data.

[0009] According to certain embodiments, an apparatus can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to receive downlink data corresponding to a narrow-band internet-of-things carrier. The at least one memory and the computer program code can also be configured to, with the at least one processor, cause the apparatus at least to conditionally multiplex the downlink data to at least one physical resource block together with other data. The other data can include data unrelated to narrow-band internet-of-things. The at least one memory and the computer program code can also be configured to, with the at least one processor, cause the apparatus at least to transmit the multiplexed data.

[0010] In certain embodiments, an apparatus can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to prepare downlink data to be transmitted on a narrow-band internet-of-things carrier. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to provide with the downlink data an indicator indicating at least one of a time or frequency resource where the downlink data is to be transmitted multiplexed with other data.

[0011] A computer program product can, according to certain embodiments, encode instructions for performing a process. The process can include receiving downlink data corresponding to a narrow-band internet-of-things carrier. The process can also include conditionally multiplexing the downlink data to at least one physical resource block together with other data. The other data can include data unrelated to narrow-band internet-of-things. The process can further include transmitting the multiplexed data.

[0012] A computer program product can, according to certain embodiments, encode instructions for performing a process. The process can include preparing downlink data to be transmitted on a narrow-band internet-of-things carrier. The process can also include providing with the downlink data an indicator indicating at least one of a time or frequency resource where the downlink data is to be transmitted multiplexed with other data.

[0013] A non-transitory computer readable medium can, according to certain embodiments, be encoded with instructions that, when executed in hardware, perform a process. The process can include receiving downlink data corresponding to a narrow-band internet-of-things carrier. The process can also include conditionally multiplexing the downlink data to at least one physical resource block together with other data. The other data can include data unrelated to narrow-band internet-of-things. The process can further include transmitting the multiplexed data.

[0014] A non-transitory computer readable medium can, in certain embodiments, be encoded with instructions that, when executed in hardware, perform a process. The process can include preparing downlink data to be transmitted on a narrow-band internet-of-things carrier. The process can also include providing with the downlink data an indicator indicating at least one of a time or frequency resource where the downlink data is to be transmitted multiplexed with other data.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0015] For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:

[0016] Figure 1 illustrates data path for overlay, according to certain embodiments.

[0017] Figure 2 illustrates resource element allocation for overlay, according to certain embodiments.

[0018] Figure 3 illustrates overlay with a distributed radio access network LTE eNB, according to certain embodiments.

[0019] Figure 4 illustrates a protocol stack according to certain embodiments.

[0020] Figure 5 illustrates overlay with a cloud RAN LTE eNB, according to certain embodiments.

[0021] Figure 6 illustrates latency in connection with certain embodiments.

[0022] Figure 7 illustrates latency estimation according to certain embodiments. [0023] Figure 8 illustrates a multiplexing method, according to certain embodiments.

[0024] Figure 9 illustrates a mechanism for supporting longer latency, according to certain embodiments.

[0025] Figure 10 illustrates support of standalone-band or guard-band deployment, according to certain embodiments.

[0026] Figure 1 1 illustrates a method according to certain embodiments.

[0027] Figure 12 illustrates another method according to certain embodiments.

[0028] Figure 13 illustrates a system according to certain embodiments. DETAILED DESCRIPTION:

[0029] Certain embodiments provide for the introduction of NB-IOT capabilities in the RAN as an overlay solution. Thus, certain embodiments can leverage the radio frequency (RF) functions of existing or conventional LTE eNBs. Moreover, certain embodiments may make improvements to the existing or conventional LTE eNB baseband to, for example, support functional changes and a lightweight interface.

[0030] For example, an entity may be introduced into the network as an overlay that interfaces to an existing or conventional LTE eNB, and that provides the eNB or baseband functionality needed for narrow-band internet of things operation. Such an entity can be referred to variously as a narrow-band internet of things access point, or an NB-IOT eNB, or an NB- IOT BBU, or an NB-IOT overlay, all substantially having the same meaning. Such an NB-IOT access point overlay can be introduced as either (i) fully virtualized implementation which provides the entire NB-IOT functionality (including L3/L2/L1), or (ii) fully bare-metal, or (iii) partly virtualized, for example only L3/L2-NRT virtualized and L2-RT/L1 on bare metal.

[0031] Also per an earlier email exchange, we can maybe clarify "bare-metal" as being "without using any virtualization, e.g. running on dedicated hardware or system-on-chip"

[0032] This overlay NB-IOT implementation, whether virtualized or bare-metal, can be placed at an edge cloud location. In certain embodiments, there may not be any need for the introduction of a new physical boxes at the existing cell site.

[0033] The transport between the edge cloud hosting the narrow-band internet of things access point and the cell site can have relaxed latency characteristics, up to ~4.5ms one-way in certain embodiments. The transport may need low incremental bandwidth added to existing IP backhaul.

[0034] Certain embodiments provide functionality that can be used over an interface between the overlay NB-IOT eNB and conventional LTE eNB. While this is described for LTE NB-IOT, the same concept can also be applied for the support of massive machine type communication (MTC) in fifth generation (5G) communication systems as well as LTE-M/LTE Cat-Mi .

[0035] Figure 1 illustrates data path for overlay, according to certain embodiments. As shown in Figure 1, two different kinds of user equipment, such as a sensor and a smart phone, can be served by an evolved Node B (eNB). A conventional LTE eNB base band unit (BBU) can perform baseband processing for conventional LTE user equipment (UEs), such as a smart phone. Internet protocol (IP) transport can carry the data corresponding to a narrow-band internet of things transmission between an overlay NB-IOT eNB and a conventional LTE eNB. The NB-IOT eNB BBU can perform baseband processing for NB-IOT signals. The NB-IOT eNB BBU may interface to an element management system (EMS). The evolved packet core (EPC) may process conventional LTE as well as narrow-band internet of things. The same EPC entities may be used to serve both conventional LTE as well as narrow-band internet of things, or different EPC entities may be used for conventional LTE and for narrow-band internet of things. As shown in Figure 1, the data corresponding to a narrow-band internet of things transmission is multiplexed with data unrelated to the narrow-band internet of things transmission, such as data for conventional LTE. In an embodiment, this may be accomplished by multiplexing a representation of the signal for narrow-band internet of things with a representation of the signal for conventional LTE. The representation of the signal may be a representation of a physical-layer signal, for instance, I/Q sample data, or a compressed version of LQ sample data, or pre-FFT or post-FFT data, or any other suitable form.

[0036] Figure 2 illustrates resource element allocation for overlay, according to certain embodiments. In some embodiments, the air interface structure allows a set of physical resource blocks (PRBs) to be used for transmissions related to narrow-band internet of things, and may be referred to generally as narrow-band internet of things carriers (NB-IOT carriers). Within these PRBs, specific resource elements (REs) are typically used for transmissions related to narrow-band internet of things, while other resource elements are used for conventional LTE transmissions, and in some cases, some resource elements may be common between NB-IOT transmissions as well as conventional LTE transmissions. The exact set of PRBs or resource elements that can be used in this way for narrow-band internet of things and/or conventional LTE may differ depending on the details of the air interface. For example, the set of PRBs or REs used by the NB-IOT standard in 3 GPP Release 13 may differ from the resource elements used for LTE-M or LTE-Category-Ml . Figure 2 illustrates an embodiment, wherein an NB-IOT carrier consisting of 1 PRB is shown. As shown in Figure 2, in physical resource blocks (PRBs) other than NB-IOT carriers, resource elements (REs) can be allocated by conventional LTE eNB as usual. Within a PRB corresponding to an NB-IOT carrier, there can be a conventional LTE physical downlink control channel (PHDCCH) region and an overlay region. In the conventional LTE PDCCH region, the first three symbols in the transmission time interval (TTI), resource elements can be allocated by a conventional LTE eNB.

[0037] The rest of the resource elements (REs), apart from LTE cell specific reference signal (CRS) REs, may be allocated by the overlay NB-IOT eNB which provides the data corresponding to the narrow-band internet of things transmission in those resource elements to the LTE eNB, which in turn multiplexes that data together with data corresponding to conventional LTE transmissions into the appropriate REs to form the full signal to be transmitted over the air.

[0038] To ensure consistency of resource allocation or for other reason, the interface between the NB-IOT and the conventional LTE eNB can support negotiation of various elements. For example, there can be a parameter indicating the starting symbol for NB-IOT.

[0039] Depending on the number of PDCCH symbols used by the LTE cell, the starting symbol can be notified to the NB-IOT eNB by the LTE cell. This may dynamically change, but as this may also need to be broadcast in system information block (SIB) messages by the NB-IOT eNB, this may only be changed slowly by the LTE eNB.

[0040] The cell ID of the NB-IOT cell and the embedding LTE cell can be provided. Similarly, the number of antenna ports of the LTE and NB-IOT cells can be provided.

[0041] It may be important to ensure that reference signals are transmitted in the right spots and there is no collision of resource elements. There can be a set of LTE PRBs that are used as NB-IOT carriers. This can be potentially static or this may be dynamically adjusted. For example, the PRBs can be dynamically adjusted in the following way. A first set of LTE PRBs can be chosen and assigned to the NB-IOT cell. This may include anchor carrier and some non-anchor carriers for NB-IOT. As the load of NB-IOT varies, the NB-IOT may request additional PRBs to use for anchor carriers as well as non-anchor carriers. The LTE eNB can then update the set of PRBs for use as NB-IOT carriers and can notify the NB-IOT eNB. Alternatively, these may be configured by operations and maintenance (O&M). [0042] Figure 3 illustrates overlay with a distributed radio access network LTE eNB, according to certain embodiments. More specifically, Figure 3 show an instantiation with distributed-RAN LTE eNB.

[0043] As shown in Figure 3, there can be a distributed RAN LTE eNB baseband unit (BBU). This may be a bare-metal, all-in-one eNB for distributed RAN. This eNB may be connected by an IP transport to an EMS for conventional LTE eNB and to a conventional EPC. Furthermore, the eNB may be connected by the IP transport to an overlay NB-IOT eNB BBU, which can communicate with an EPC for NB-IOT.

[0044] Figure 4 illustrates a protocol stack according to certain embodiments. More specifically, Figure 4 illustrates a protocol stack for the case where the conventional LTE eNB is a distributed-RAN eNB. Two paths are shown: a first path shown with a solid line for the processing of signals corresponding to conventional LTE, and a second path shown with a broken line for the processing of signals corresponding to narrow-band internet of things.

[0045] As shown in Figure 4, data corresponding to narrow-band internet of things can be multiplexed (in downlink) or demultiplexed (in uplink) with data for conventional LTE. This multiplexing or demultiplexing may occur based on physical layer (LI) data, or based on a modified form of physical layer data (sometimes referred to as LI ') which may include, for example, pre-FFT data on downlink or post-FFT data on uplink. A backhaul interface for the conventional LTE eNB, which may use an internet protocol (IP)-based transport, can transport both SI protocol packets to or from the EPC as well as packetized data for narrow-band internet of things to or from the overlay NB- IOT eNB. An overlay NB-IOT eNB can perform multiple layers of protocol and signal processing for narrow-band internet of things, including either full physical layer (LI) processing or partial physical layer processing (sometimes known as LI '). The overlay NB-IOT eNB may be virtualized or not virtualized. [0046] A conventional LTE eNB may be modified to take on additional functionality, for example to accomplish the features shown in Figure 4, or for other reasons. For example, the eNB can be configured to multiplex (Mux) downlink (DL) LI or LI ' data received from NB-IOT eNB for PRBs corresponding to NB-IOT carriers. For another example, the eNB can also be configured to demultiplex (Demux) uplink (UL) LI or LI ' data to send to an NB-IOT eNB for PRBs corresponding to NB-IOT carriers.

[0047] Figure 5 illustrates overlay with a cloud RAN LTE eNB, according to certain embodiments. More particularly, Figure 5 illustrates an embodiment wherein the conventional LTE eNB is a cloud RAN eNB or a cloud BTS. In this embodiment, for conventional LTE, a portion of the conventional LTE baseband functions, for example non-real-time baseband functions (referred to as BB-NRT) are performed in a virtualized manner in an edge cloud. Other baseband functions for the conventional LTE, for example real-time baseband functions(referred to BB-RT), are typically performed in a non-virtualized manner at a baseband unit which may be closer to the cell-site from where over-the-air transmissions will take place.

[0048] In the embodiment of Figure 5, the BB-RT module can multiplex narrow-band internet of things data along with conventional LTE data for transmission in downlink, or demultiplex after reception in uplink. The multiplexing or demultiplexing of data may happen at LI or LI ' in a manner similar to the embodiment of Figure 4. The data for narrow-band internet of things can be sent between the BB-RT module and an overlay NB-IOT eNB via an IP transport network. The overlay NB-IOT eNB may perform all or part of the baseband protocol and signal processing for narrow-band internet of things. The overlay NB-IOT eNB itself may be virtualized and/or hosted in the edge cloud along with the BB-NRT for conventional LTE.

[0049] The NB-IOT overlay eNB may be managed by the same EMS as the conventional LTE eNB, or a separate one. In case of virtualized instantiation, the virtualized NB-IOT eNB may be created in the same cloud data center as the cloud-LTE BTS, or a separate data center. If the same cloud data center is used, a common management and orchestration framework may be used for both the NB-IOT virtualized overlay as well as the conventional LTE cloud BTS.

[0050] Figure 6 illustrates latency in connection with certain embodiments. Thus, for example, Figure 6 illustrates latency tolerance of the interface between overlay NB-IOT eNB and Conventional LTE eNB.

[0051] Conventional LTE has a very tight hybrid automatic repeat request (HARQ) operation for peak throughput. This tight operation can put significantly tight constraints on fronthaul latency for conventional LTE. NB-IOT, by contrast, has characteristics that may allow significantly relaxation of the latency needs. For example, NB-IOT uses asynchronous HARQ, unlike LTE which uses synchronous HARQ on UL. Furthermore, there may be no synchronous/implicit retransmissions by NB-IOT UE. Instead, acknowledgment / negative acknowledgment (ACK/NACK) and retransmission (retx) grant can be explicitly provided by RAN in downlink control information (DCI) over narrow-band physical downlink control channel (NB-PDCCH). By contrast, in LTE the UE would automatically retransmit 4 transmission time intervals (TTI) after initial physical uplink shared channel (PUSCH) Tx if ACK/NACK not received on physical HARQ indicator channel (PHICH), which can constrain the fronthaul latency in LTE.

[0052] NB-IOT is designed for very low throughput - just one HARQ process anyway - thus peak throughput is not important. By contrast, normal LTE operation for broadband traffic may have a need to maintain peak throughput by avoiding HARQ stall. This need to maintain peak throughput can significantly constrain the fronthaul latency.

[0053] Further, NB-IOT UEs may not be expected to support high mobility and seamless handover. Thus, additional latency will also not degrade the control-plane ley performance indicators (KPIs), such as handover failure rates. Due to this, even the real-time baseband functions of NB-IOT (L2/Sch/Ll) can be at significant latency away from the RF, for example 5ms one-way. Due to RACH response timing, the maximum latency may be limited to ~4.5s.

[0054] Figure 6 shows NB-IOT UE Tx RACH on UL. The eNB sends RACH response. At transmission time interval (TTI) N, the UE sends PRACH in this example. At TTI N+6, the network can send the PRACH response. However, as a maximum (Max) RACH response window may be 10 ms, a response could be sent as late as TTI N+13. The RACH response window size can have a maximum value of 10 subframes, starting from TTI N+3 in this example. The latency budget available for the interface between NB-IOT eNB and the cell site may thus be 12 ms minus the processing time of NB-IOT baseband. The NB-IOT baseband processing time may include both the actual processing of LI uplink, scheduling, DL medium access control (MAC), and LI downlink, and also fronthaul latency before and after such processing.

[0055] The latency budget can thus be constrained by the RACH window, which is a defined value in third generation partnership project (3 GPP) to 12 ms - (processing time of NB-IOT baseband).

[0056] Conventional LTE eNB baseband processing is around 3ms. Since NB-IOT is just one PRB, NB-IOT baseband processing time may be significantly less than 3ms. Thus, NB-IOT fronthaul round trip travel (RTT) budget is around 9ms or a bit higher, but limited to 12ms RTT max.

[0057] In certain embodiments, the max value of the RACH response window advertised in SIB2 can be changed. When a user equipment performs a RACH transmission, it may expect a response within a certain window called a RACH response window. The value of this window can be advertised in system information broadcast 2 (SIB 2) messages. The latency of the transport network between the conventional LTE eNB and the overlay NB-IOT eNB can affect the time it takes for the NB-IOT eNB to respond to RACH requests received from NB-IOT UEs. In certain embodiments, the overlay NB-IOT eNB may generate SIB2 messages that indicate an enlarged RACH response window to narrow-band internet of things UEs, for example to allow for a greater latency tolerance on the transport network between the conventional LTE eNB and the overlay NB-IOT eNB.

[0058] Figure 7 illustrates latency estimation according to certain embodiments. As shown in Figure 7, latency can be measured using a protocol such as two-way active measurement protocol (TWAMP) to determine latency over IP transport between the conventional LTE BB RT and the overlay NB-IOT eNB BBU.

[0059] For jitter and synchronization needs, a conventional eNB may have its own global positioning system (GPS), and may controls its own common public radio interface (CPRI) link to its own remote radio head (RRH). The conventional eNB does not need to be dependent on the NB-IOT eNB for synchronization purposes, and the NB-IOT eNB need not have a very stringent synchronization interface towards the conventional eNB's radio head.

[0060] Moreover, the interface between the NB-IOT eNB and the conventional eNB does not need to provide a CPRI-type precise timing/frequency reference or phase synchronization (sync) to the conventional eNB. Accordingly, a relaxed jitter, packetized transport may be adequate.

[0061] As shown in Figure 7, the NB-IOT eNB can estimate the latency between itself and the conventional LTE eNB. For example, the interface between the NB-IOT and LTE eNB can support the TWAMP protocol, which may be suitable for latency estimation. Other protocols are also permitted. Accuracy of synchronization may be, for example, to the level of 1ms. Jitter in the measurements can be estimated and added to the latency estimate, to give an added safeguard. Moreover, the NB-IOT can round up the estimated latency to the next-higher 1ms value, for safety. Furthermore, the NB-IOT can periodically monitor the latency of the link, in case the latency is variable and changes over time. [0062] What is referred to as a conventional LTE eNB may be called that to distinguish it from the NB-IOT eNB. Nevertheless, the conventional LTE eNB may contain various modifications and configurations that are not actually conventional. For example, the conventional LTE eNB can be configured to multiplex DL, LI or LI ', data received from NB-IOT eNB for PRBs corresponding to NB-IOT carriers. Similarly, the conventional LTE eNB can be configured to demultiplex UL, LI or LI ', data to send to NB-IOT eNB for PRBs corresponding to NB-IOT carriers.

[0063] Figure 8 illustrates a multiplexing method, according to certain embodiments. More particularly, Figure 8 illustrates multiplexing data into correct subframe at the LTE eNB.

[0064] At the conventional eNB, the LD LI (or LI ') data received from the NB-IOT can arrive with some potentially variable jitter/latency, and may need to be multiplexed into the appropriate sub-frame for over-the-air transmission.

[0065] The LTE eNB can send time-stamped messages at the start of a subframe to the overlay NB-IOT eNB indicating frame, subframe number or any suitable timing reference indication. These time-stamped messages can be sent at some periodicity: either every subframe, or every frame, or some suitable periodicity, or may even be sent aperiodically.

[0066] The NB-IOT eNB can then use its estimate of the latency of the path to the LTE eNB together with the time-stamped messages to know which is the current TTI. In an embodiment, the NB-IOT eNB can use this estimated latency to determine how early the narrow-band internet of things data corresponding to a given frame/subframe needs to be sent so as to ensure that it will be received at the conventional LTE eNB early enough to allow multiplexing with conventional LTE data and transmission in the desired frame/subframe. The latency can be estimated using, for example, TWAMP.

[0067] The Ll/Ll ' data sent by the NB-IOT eNB to the LTE eNB can be packetized and each packet can indicate an appropriate indication of a time and/or frequency resource, such as a frame/subframe number and/or symbol number and/or PRB or subcarrier index or narrow-band carrier index, into which the LTE eNB should multiplex that narrow-band internet of things data.

[0068] This indication can ensure that the LTE eNB can multiplex the DL data sent by the NB-IOT eNB into the correct resources over the air. This may be particularly valuable for certain subframes, which carry information like primary synchronization signal (PSS), or the like, which may need to occur with deterministic timing.

[0069] If the data sent by the NB-IOT enB to the LTE eNB arrives at the LTE enB too late to be multiplexed into the indicated sub-frame, then the LTE enB can send an indication to the NB-IOT eNB. The indication can, for example, indicate that the data was too late. Optionally, the indication can further indicate the amount of time by which the data was too late, which may allow the NB-IOT to adjust its latency/jitter estimate.

[0070] At the NB-IOT eNB, the execution of L2/L1 processing of a given TTI can be left-shifted by the estimated one-way latency, that is, executed earlier in time by an amount based on the latency, to ensure that the processing finishes sufficiently early for the NB-IOT data to be received at the conventional eNB in time. The amount of the left-shift can be adjusted based on the data too late indication.

[0071] As shown in Figure 8, the NB-IOT eNB can perform path latency estimation. Then, at some subsequent time, the conventional LTE eNB can send a TTI start indication, which can include information such as frame and/or subframe. The NB-IOT eNB can perform L2/L1 processing for subframe N, and can send DL data for subframe N, including frame/subframe number. If the data arrives in time, the LTE eNB can multiplex the downlink data into an appropriate subframe.

[0072] Subsequently, the NB-IOT eNB can perform L2/L1 processing for subframe N+l, and can send DL data for subframe N+l, including frame/subframe number. If the data is received too late, then the LTE eNB can stop from multiplexing the DL data into a subframe, as it may be too late to do so into the appropriate subframe. The LTE eNB can, however, send an indication of data received too late to the NB-IOT eNB.

[0073] For UL retransmissions, the UE has to be awake to monitor for the NB- PDCCH grants for ACK/NACK and retransmissions, and the UE starts monitoring >3ms after the original PUSCH Tx. If the NB-IOT eNB is only going to respond after a longer latency, this is wasted battery at the NB-IOT UE to monitor for the NB-PDCCH.

[0074] It is still desirable to minimize the latency between the NB-IOT baseband and the RF, because of some battery life impact to the NB-IOT UE. However, in case the latency to the NB-IOT enB is longer, the following enhancement can be used.

[0075] There can be various enhancements to minimize battery wastage when monitoring for UL ACK/nack and retransmission grant. For example, the NB- IOT eNB can provide a parameter to the NB-IOT UE (e.g. by RRC) to provide an enlarged offset between the timing of the PUSCH transmission and the minimum timing of the DCI that will provide the ack/nack and retransmission grant, that accounts for the additional fronthaul latency.

[0076] Figure 9 illustrates a mechanism for supporting longer latency, according to certain embodiments. This may be a potential enhancement for NB-IOT UE battery life to support longer latency. As shown in Figure 9, after the NB-IOT eNB performs path latency estimation, the NB-IOT eNB can indicate to the NB-IOT user equipment a minimum offset between PUSCH transmission timing and timing of DCI with ack/nack and transmission information. This indication can be provided, for example, in a radio resource control (RRC) message.

[0077] The NB-IOT eNB can estimate the latency between itself and the conventional LTE eNB. For example, the interface between the NB-IOT and LTE eNB can support TWAMP. The NB-IOT eNB can use this estimated latency in providing the offset/timing parameter to the NB-IOT UE.

[0078] Figure 10 illustrates support of standalone-band or guard-band deployment, according to certain embodiments. Thus, Figure 10 illustrates an example of support of guard-band or standalone-band deployment of NB-IOT. The above discussion has addressed support of in-band NB-IOT using an overlay NB-IOT eNB along with a conventional LTE eNB, NB-IOT may also be deployed in the frequencies corresponding to the guard band of conventional LTE carrier, or as a standalone carrier, for example refarmed GSM carrier.

[0079] In this case the NB-IOT eNB can directly interface to the RRH supporting the guard-band/standalone NB-IOT carrier. There may be no need for multiplexing LTE eNB's resource allocation with NB-IOT enB's resource allocation, or the like. The same latency/jitter-tolerant interface considerations can still apply to the interface between the NB-IOT eNB and the RRH.

[0080] As illustrated in Figure 10, there can be two data paths through the system: from the overlay NB-IOT-eNT BBU to the RRH for guard-band standalone-band NB-IOT and from the overlay NB-IOT-eNT BBU to the conventional LTE BB-RT. The former path can be used for standalone / guard-band NB-IOT, whereas the latter can be used for in-band NB-IOT. Both paths can go through the IP transport and additionally through a cell-site router. Even for a standalone or guard-band deployment of narrow band internet of things, the latter path can be used. That is, even for standalone or guard-band NB-IOT deployment, the NB-IOT eNB may interface to a conventional eNB which connects to a remote radio head (RRH). In this case, the conventional eNB may not need to multiplex the narrowband internet of things data with conventional LTE data, but may instead just act as a conduit between the NB-IOT eNB and the RRH. There may still be advantages to using this way of deployment, for example simplifying the management and synchronization of the RRH. [0081] Figure 11 illustrates a method according to certain embodiments. The method can include, at 1110, receiving downlink data corresponding to a narrow-band internet-of-things carrier. The data corresponding to the narrow-band internet-of-things carrier can be a representation of a signal or protocol data for a narrow-band internet-of-things transmission, for example layer one (LI) or layer one prime (LT) data.

[0082] The data corresponding to the narrow-band internet-of-things carrier can be packetized data. Each packet of the packetized data can include an indicator that indicates that provides a time or frequency index indicating where the data corresponding to the narrow-band internet-of-things carrier is to be multiplexed. For example, the indicator can indicate at least one of a frame or subframe number into which the data corresponding to the narrowband internet-of-things carrier is to be multiplexed. More generally than a frame or subframe number, the indication may be a time indication for a particular symbol within a subframe, and may include a frequency indication like a PRB number (or subcarrier number), or a resource element indication (time+frequency). A broad range of time/ frequency/ resource indications may be used.

[0083] The method can also include, at 1120, conditionally multiplexing the downlink data to at least one physical resource block together with other data. The other data can be data unrelated to narrow-band internet-of-things. For example, it can be the conventional LTE eNB data. The method can further include, at 1130, transmitting the multiplexed data on the narrowband internet-of-things carrier. Transmitting the multiplexed data can refer to transmitting the multiplexed data over the air, but can also refer to sending the multiplexed data from a baseband unit to a remote radio head for transmission over the air, for example in the form of I/Q samples over a common public radio interface (CPRJ).

[0084] The method can additionally include, at 1 105, sending at least one time-stamped message indicating a time reference to a narrow band internet of things access point, for example sending a time-stamped message at a start of a subframe, indicating the subframe, to a narrow-band internet-of- things access point periodically. A value of the indicator that indicates at least one of the frame or subframe number can be based on the time-stamped message.

[0085] The method can further include, at 1 115, determining whether to multiplex the downlink data based on the indicator. The method can additionally include, at 1 125, when the determination is not to multiplex the downlink data, sending an indication of a reason for the determination to a narrow-band internet-of-things access point

[0086] Figure 12 illustrates another method according to certain embodiments. A method can include, at 1210, preparing downlink data to be transmitted on a narrow-band internet-of-things carrier. The method can also include, at 1220, providing with the downlink data an indicator indicating at least one of a time or frequency resource where the downlink data is to be transmitted multiplexed with other data. A value of the indicator can be based on receipt of a time-stamped message. The message can be one of a plurality of messages sent at a predetermined periodicity.

[0087] The method can further include at 1230, determining a latency between a narrow-band internet-of-things access point and another access point. The method can additionally include, at 1240, calculating a value for the indicator based on the latency. The method can also include, at 1245, adjusting an indication of a RACH response window in system information broadcast messages based on the determined latency.

[0088] The method can also include, at 1250, transmitting the downlink data with the indicator. The method can further include, at 1260, receiving an indication that the downlink data was received too late to be multiplexed. The method can further include, at 1270, adjusting an offset for a value of an indicator for a subsequent downlink data. The method can additionally include, at 1280, recalculating the latency based on the indication. [0089] Figure 13 illustrates a system according to certain embodiments of the invention. In one embodiment, a system may include multiple devices, such as, for example, at least one UE 1310, at least one NB-IOT access point 1320, which may be an eNB, or other base station or access point, and at least one other access point 1330, which may be an LTE access point, such as the conventional LTE eNB mentioned above.

[0090] Each of these devices may include at least one processor, respectively indicated as 1314, 1324, and 1334. At least one memory can be provided in each device, and indicated as 1315, 1325, and 1335, respectively. The memory may include computer program instructions or computer code contained therein. The processors 1314, 1324, and 1334 and memories 1315, 1325, and 1335, or a subset thereof, can be configured to provide means corresponding to the various blocks of Figures 11 and 12.

[0091] As shown in Figure 13, transceivers 1316, 1326, and 1336 can be provided, and each device may also include an antenna, respectively illustrated as 1317, 1327, and 1337. Other configurations of these devices, for example, may be provided. For example, other access point 1330 may be configured for wired communication, in addition to wireless communication, and in such a case antenna 1337 can illustrate any form of communication hardware, without requiring a conventional antenna.

[0092] Transceivers 1316, 1326, and 1336 can each, independently, be a transmitter, a receiver, or both a transmitter and a receiver, or a unit or device that is configured both for transmission and reception.

[0093] Processors 1314, 1324, and 1334 can be embodied by any computational or data processing device, such as a central processing unit (CPU), application specific integrated circuit (ASIC), or comparable device. The processors can be implemented as a single controller, or a plurality of controllers or processors.

[0094] Memories 1315, 1325, and 1335 can independently be any suitable storage device, such as a non-transitory computer-readable medium. A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory can be used. The memories can be combined on a single integrated circuit as the processor, or may be separate from the one or more processors. Furthermore, the computer program instructions stored in the memory and which may be processed by the processors can be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language.

[0095] The memory and the computer program instructions can be configured, with the processor for the particular device, to cause a hardware apparatus such as UE 1310, NB-IOT access point 1320, and other access point 1330, to perform any of the processes described herein (see, for example, Figures 11 and 12). Therefore, in certain embodiments, a non-transitory computer- readable medium can be encoded with computer instructions that, when executed in hardware, perform a process such as one of the processes described herein. Alternatively, certain embodiments of the invention can be performed entirely in hardware.

[0096] Furthermore, although Figure 13 illustrates a system including a UE, NB-IOT access point, and other access point, embodiments of the invention may be applicable to other configurations, and configurations involving additional elements. For example, not shown, additional UEs may be present, and additional core network elements may be present.

[0097] Certain embodiments may have various benefits and/or advantages. For example, certain embodiments may enable rapid introduction of NB-IOT, as possibly fully virtualized overlay, without disrupting existing LTE deployments. Furthermore, certain embodiments may enable co-hosting at edge cloud of NB-IOT (virtualized) RAN with (virtualized) EPC optimized for NB-IOT, as well as possibly with application-layer frameworks.

[0098] Certain embodiments may provide an opportunity for an operator to provide a vertically integrated platform for IOT including EPC and RAN. Moreover, certain embodiments may enable early introduction of network- slicing for IOT, such as an end-to-end (E2E) IOT slice that is fully virtualized and customizable to needs of individual tenants

[0099] One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention.

[0100] List of Abbreviations

[0101] LTE = Long Term Evolution

[0102J NB-IOT = Narrow-band Internet Of Things

[0103] eNB = evolved Node B

[0104] EPC = Evolved Packet Core

[0105] LTE-M = LTE Cat-Mi

[0106] LTE-Cat-Ml = LTE category Ml

[0107] eMTC = enhanced Machine Type Communication

[0108] RRH = Remote Radio Head

[0109] EMS = Element Management System

[0110] IP = Internet Protocol

Claims

WE CLAIM:

1. A method, comprising:

receiving downlink data corresponding to a narrow-band internet-of- things carrier;

conditionally multiplexing the downlink data to at least one physical resource block together with other data, wherein the other data comprises data unrelated to narrow-band internet-of-things; and

transmitting the multiplexed data.

2. The method of claim 1, wherein the transmitting the multiplexed data comprises transmitting the multiplexed data on the narrow-band internet-of-things carrier.

3. The method of claim 1 or claim 2, further comprising:

providing information related to a narrow-band internet of things cell, wherein the information comprises at least one of cell-ID and number of antenna ports.

4. The method of any of claims 1-3, further comprising:

receiving a request for resources needed for narrow-band internet of things transmissions; and

adjusting a set of resources used for narrow-band internet of things transmissions as well as resources used for transmissions other than narrowband internet of things, based on the request.

5. The method of any of claims 1-4, further comprising:

notifying a starting symbol to a narrow band internet-of-things access point.

6. The method of any of claims 1-5, wherein the data corresponding to the narrow-band internet-of-things carrier comprises a representation of a signal or protocol data for a narrow-band internet-of-things transmission.

7. The method of any of claims 1-6, wherein the data corresponding to the narrow-band internet-of-things carrier comprises an indicator that provides a time or frequency index indicating where the data corresponding to the narrow-band internet-of-things carrier is to be multiplexed.

8. The method of any of claims 1-7, further comprising:

sending at least one time-stamped message indicating a time reference to a narrow band internet of things access point.

9. The method of claim 7 or claim 8, further comprising:

determining whether to multiplex the downlink data based on the indicator.

10. The method of claim 9, further comprising:

when the determination is not to multiplex the downlink data, sending an indication of a reason for the determination to a narrow-band internet-of- things access point.

11. A method, comprising:

preparing downlink data to be transmitted on a narrow-band internet- of-things carrier; and

providing with the downlink data an indicator indicating at least one of a time or frequency resource where the downlink data is to be transmitted multiplexed with other data.

12. The method of claim 11, further comprising:

determining a latency between a narrow-band internet-of-things access point and another access point; and

calculating a value for the indicator based on the latency.

13. The method of claim 12, further comprising:

determining a value of an offset between the timing of the transmission of an uplink data transmission and the timing of at least one of an acknowledgment/negative acknowledgement, a retransmission indication, or a new transmission grant; and

sending a message to a user equipment or a broadcast message to indicate the value of the offset.

14. The method of claim 11 or claim 12, wherein an indication of a random access channel response window in system information broadcast messages is adjusted based on the determined latency.

15. The method of any of claims 11-14, wherein preparing the downlink data comprises preparing a representation of a signal or protocol data to be transmitted.

16. The method of any of claims 11-14, further comprising:

monitoring a load or utilization of narrow-band internet-of-things; and

sending a request for resources needed for narrow-band internet of things transmissions.

17. The method of any of claims 11-15, further comprising:

transmitting the downlink data with the indicator.

18. The method of any of claims 11-16, wherein a value of the indicator is based on receipt of a time-stamped message indicating a time reference.

19. The method of any of claims 11-17, further comprising:

receiving an indication that the downlink data was received too late to be multiplexed.

20. The method of claim 18, further comprising:

adjusting an offset for a value of an indicator for a subsequent downlink data.

21. The method of claim 18 or claim 19, further comprising:

recalculating the latency based on the indication.

22. An apparatus, comprising:

at least one processor; and

at least one memory including computer program code,

wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform a process, the process comprising the method according to any of claims 1-20.

23. An apparatus, comprising:

means for performing a process, the process comprising the method according to any of claims 1-20.

24. A computer program product encoding instructions for performing a process, the process comprising the method according to any of claims 1-20.

25. A non-transitory computer-readable medium encoded with instructions that, when executed in hardware, perform a process, the process comprising the method according to any of claims 1-20.