The QoS (Quality of Service) is not a specific technology per se; instead, it’s a “set of requirements” that needs a precise definition before design and implementation. If the requirement is to achieve low latency and zero packet-loss, one deployment scenario would be -matching and marking traffic at the network ingress and implement appropriate scheduling at the egress. Such scheduling often requires vendor-specific queuing technology. If minimum jitter was the requirement -we may need to eliminate indeterministic path-selection for the traffic. Especially in a big SP network, the technology to do so can be as sophisticated as MPLS-TE with FRR.
Intuitively, the desired QoS deployment should realize smaller latency/packet-loss/jitter and higher data-rate. An operator always strives to maintain such good QoS-profile for mobile broadband service.
But, this traditional way of contemplating QoS has changed with the introduction of machine type communication (MTC). The broadband centric QoS paradigm failed to meet MTC requirements and forced 3GPP has to invent and re-engineer multiple technologies to support MTC. Although the specification didn’t use the term “QoS”, the QoS can be an interesting perspective to evaluate the MTC use-cases.
The mMTC (massive-MTC) targets 1-Million connections per square kilometer in 2 hours, and many of them will be in extreme coverage condition. So, the mMTC emphasizes low data-rate with high latency. The minimum data-rate permitted is 160-bps at 164-dB MCL with maximum allowed latency of 10-second (Maximum Coupling Loss -it measures the difference in the power level between transmitter and receiver). By comparison, even a 2G network looks over-engineered for such a QoS profile. Another unique aspect is that IoT devices expected to have 10-years runtime using a none-rechargeable battery with a 5-watt-hour power rating.
LTE-M and NB-IoT are two re-engineered legacy LTE technology to address the mMTC requirement of 160-bps data-rate, 10-s latency, 10-years battery life and 140-connection per second (this is equivalent to 1-M connection in 2 hours).
Long battery life implies that a device cannot transmit at high power-level even if it’s in an extreme-coverage location. To overcome this limitation, all mMTC communication technologies, including 2G EC-GSM-IoT, uses blind-repetition. With blind-repetition both the device and network send multiple copies of the same signal. On the receiver side, the repeated signal gets combined in a soft buffer before any digital processing. The soft-combination as it known, dramatically improves SINR, hence increases the chance for successful demodulation and decoding.
LTE-M has two coverage-enhancement (CE) specification that an LTE device may support- CE mode-A and CE mode-B. The CE Mode-B is optional. Each CE mode has several CE-levels; these levels determine the number of blind-repetitions. The NB-IoT has coverage-class (CC) from 0 to 4, like LTE, each CC with multiple CE-levels. Coverage-class 0 means good coverage. An IoT device calculates the CE-level by comparing RSRP/RSRQ between the received signal and the network advertised value (RSRP/RSRQ -Reference Signal Received Power/Quality). The device lets the network know about it’s CE-level during initial random access using a specific preamble format. In case of a failed initial-access, a device can increase it’s CE-level in its next attempt. On the other hand, the network monitors uplink quality and may instruct the device to fallback to specific CE-level using the so-called DCI transport-channel.
A question may arise, why two IoT technologies for LTE?
The LTE-M has two device categories- CAT-M1 operates at 1.4-MHz narrowband, and CAT-M2 operates at 5-MHz wideband. Both work seamlessly within regular 20-MHz LTE carrier. Due to the higher data-rate, the CAT-M2 is more suitable for the so-call broadband-IoT uses-case. Moreover, CE-mode described above not limited to CAT-M devices only; any higher category LTE device can implement these coverage enhancements. As a result, LTE-M is more of a natural evolution of legacy LTE.
The NB-IoT, on the other hand, was re-engineered to compete with growing unlicensed LPWAN technologies (Low Power Wide Area Networks) -like Sigfox and LoRa. Unlike LTM-M, which only needs a software upgrade on eNB to support additional protocol-stack, the NB-IoT also needs a proper deployment plan. Since NB-IoT operates within a thin 200-kHz spectrum, there are three deployment models to choose from -Standalone, In-band, and Gaurd-band.
Both LTE-M and NB-IoT devices support either PSM or DRX/eDRX cycle in which the device goes to idle-mode to preserve battery life. In DRX/eDRX, the devices occasionally switch to connected-mode entering PO (Paging Occasion) to receive data from the network. To avoid unnecessary waking up in case no data is scheduled for the device, a new physical channel -MWUS (MTC Wake-Up Signal) is specified. The MWUS notify the device if any MT (Mobile Terminated) data available in the upcoming PO. While sleeping, all devices listen to the MWUS channel, if no data indicated in MWUS, the device enter into the next eDRX cycle without leaving idle-mode.
There is a different set of features for the MO (Mobile Originated) case. RRC-resume is one such feature part of User-Plane CIoT EPS Optimization specification. RRC-resume -1/ keep PDCP session suspended during idle-mode; as a result, no RRC configuration required when changing to connected-mode; 2/ multiplex small user-plane data over RRC-resume messages. Similar, but for control-plane, the DoNAS (Data over Non-Access Stratum) was specified in Control-Plane CIoT EPS Optimization. It provides a container to carry user-plane data in the RRC-connection setup message. In both RRC-resume and DoNAS, if the MO data is sufficiently small, device complete data transfer as soon as it enters the connected-mode. The EDT (Early Data Transmission), a Rel-15 feature allows user-plane data multiplexing on the RRC connection-resume request message instead, with this enhancement, a device can complete data transfer in the idle-mode, without even going into connected-mode.
So, why two mMTC technologies in LTE?
Despite low data-rate compare to LTE-M, the NB-IoT has better-extended coverage performance. The basic NB-IoT supports approximately 60,000 devices per square kilometer; however, Rel-14 extended this number to 1-Million. In all aspects, the NB-IoT almost fulfilled the 5G mMTC requirements. As a result, 3GPP didn’t specify any new technology for mMTC in 5GS; instead, it opted for NB-IoT and LTE-M coexistence with NR. The 5GS support Reserved-Resource to exclude NR from using a particular time domain and frequency domain resources. It allows seamless fusion of LTE mMTC bands within the NR spectrum. So, unless NB-IoT requires to operate at the higher frequency or to support larger SCS than 15-kHz (SCS -Subcarrier Spacing), there will be no need for a native 5GS mMTC technology.
At the opposite extreme of the MTC use-cases, the so-called cMTC (critical-MTC) requires an air-interface of 1-millisecond latency with 99.999% reliability. Both LTE and 5G-NR URLLC (Ultra-Reliable Low Latency Communications, Rel-15) meet these requirements. Technically, this is the upper bound of the LTE; more advanced requirement, as described below, needs new technology like the 5G.
One unique cMTC use-case, so-called industrial-IoT (IIoT) focuses on industrial automation and cyber-physical systems. In a cyber-physical operation, a digital representation of the physical system is built from real-time data using high-resolution sensors, cameras, etc. All decisions are derived from the digital-domain through simulation and forwarded to the physical domain for execution.
As it sounds, IIoT needs more stringent QoS then conventional cMTC -0.5-ms air-interface latency, six-9 reliability, and 1-microsecond clock synchronization. The 1-μs clock precision aims to replace both Fieldbus and Ethernet-based TSN connectivity with the 5G NR (Time-Sensitive Networking -IEEE 802.1). The LTE can provide only rough time-synchronization to the device. The NR in Rel-16, on the other hand, supports synchronization with multiple high-precision external clocks.
To comply with the QoS for URLLC, the 3GPP minimize the transmission time for both LTE and NR. The smallest time-resource for both the technology is an OS (OFDM Symbol), while the lowest frequency resource is a subcarrier. The smallest schedulable unit is called -RE (Resource Element) consists of a subcarrier and an OS.
The minimum transmission time for LTE is 14-OS, aka a subframe, which is equivalent to 1-ms. It’s because a subframe contains 84-RE (in a PBR -Physical Resource Block containing 12-Subcarrier) out of which many contain control information (so-call reference-signal) which must be received before digital processing can proceed. One such reference-signal is DMRS (Demodulation Reference Signal). The DMRS is encoded in multiple RE in a subframe using a deterministic mathematical sequence, this sequence is known to both eNB/gNB and the device. By comparing the received DMRS with known sequence, the device can easily calculate the interference; this allows coherent demodulation of the rest of the OS within the same subframe.
In Rel-15, the URLLC requires the LTE to support both slot and sub-slot transmission. A subframe consists of two slots; so a slot consists of 7-OS and has a time duration of 0.5-ms.
The NR natively support slot transmission. Moreover, to further reduce the transmission duration, the NR supports the so-called mini-slot transmission and higher SCS (example -30-kHz/60-kHz). The SCS minimizes the OS duration at the expense of a broad spectrum.
The main difference between LTE and NR slot transmission is that NR mini-slot supports front-loaded DMRS, i.e. first OS contains the DMRS. The DMRS reception at the beginning allows immediate demodulation of the subsequent OS even before mini-slot transmission is complete.
In most scenarios, the URLLC will be a local area communication technology, operating in high frequency within an industrial premise. Although individual URLLC device may not generate substantial traffic, thousands of such devices within a small geographic location may produce a massive amount of data. Transferring such voluminous data to a central cloud may not be feasible. As a result, besides low-latency and high-reliable air-interface, the URLLC also requires local computing resources (MEC -Mobile Edge Computing) for data processing.
So, the relevant question may arise -what caused such a remarkable transformation in mobile communication technology? An explanation might be, in a short team, the QoS influence the design and deployment of technologies. But, over a long period, the QoS might be the prime driver for technological evolution.
For more detail on MTC, an interested reader can refer to the 735-page magnum-opus Cellular Internet of Things: From Massive Deployments to Critical 5G Applications [2nd Edition] by Olof Liberg et al.