# Evolution and Testing of NB-IoT Solutions
## 3 Close-Up View of the NB-IoT Standard: NB-IoT Internals  
NB-IoT has been integrated into LTE standards; however, it introduces a new radio interface for LTE, which is compatible with LTE deployments. This means that, although there is not backwards compatibility in all scenarios, it can coexist with current cellular deployments. In order to enable this coexistence, NB-IoT supports three different operation modes: in-band, guard-band, and standalone modes. In the in-band mode, NB-IoT can use one physical resource block within a normal LTE carrier; for guard-band mode, NB-IoT deployment can use the unused resources block within a LTE carrier's guard-band and, in the standalone mode, a dedicated carrier is required from 2G/3G refarming.  
As shown, the in-band and guard-band operation modes are compatible with standard LTE deployments; however, the new RF channel bandwidth of 200 kHz (180 kHz plus guard-band, this is why these modes use only one LTE physical resource block of 180 kHz) requires new control and data channels. Relevant modifications in the physical layer, other than those already mentioned to work with narrowband channels, are the half duplex operation in FDD (Frequency Divising Duplexing), to reduce the maximum modulation scheme supported to QPSK and the higher number of repetitions  
Figure 1: NB-IoT in numbers.  
used to enhance the coverage, up to 1048 repetitions in downlink channels and 128 repetitions in uplink channels. MAC (Medium Access Control), RLC (Radio Link Control), PDCP (Packet Data Convergence Protocol), and RRC (Radio Resource Control) procedures are based on existing LTE procedures and protocols in addition to some optimization to support channelization and the selection of the physical layer.  
Apart from the changes made in the radio interface, signaling protocols and architecture have also been optimized. In general, these modifications seek to simplify the signaling procedures to reduce the overhead introduced by them, and therefore provide simplified versions of S1, S1-lite, and NAS, SNAS (Simplified NAS), and a new element called C-SGN (Cellular IoT Serving Gateway Node), which provides combined C-plane and U-plane functions, e.g., aggregating some of the functions that traditionally reside in MME (Mobility Management Entity) and SGW (Serving Gateway). P-GW (Packet Gateway) is only used to support the roaming case. For the non-roaming case, SGi interface terminates on C-SGN, and C-SGN can send/receive data on SGi directly. Figure 2 shows the NB-IoT architecture proposed in 3 GPP TR 23.720 [11].  
The other key issue which has determined NB-IoT architecture is the efficient support of infrequent, small data transmission. To address this requirement, the 3 GPP in 3 GPP TR 23.720 [11] has proposed a control plane optimization called DoNAS (Data over NAS), as the mandatory solution for the transport of IP data, non-IP data, and SMS. In this solution, NAS messages are used to carry user data which prevents having to set up DRB (Dedicated Radio Bearer), S1-U bearers and AS (Application Server) security, and reduces the signaling procedures in the core network and also in the radio access.  
As an optional implementation, a user plane solution has also been proposed, based on an improvement of RRC, introducing two new procedures, \"RRC Suspend\" and \"RRC Resume\" and the storage of AS (Access Stratum) information in the UE. All of these enable the signaling overhead to be reduced when the UE (User Equipment) transits from RRC Idle to RRC connected mode and also returns to RRC Idle mode faster. Initially, this second solution will only be applicable to IP data transport and SMS; however, it can be combined with other solutions proposed in 3 GPP TR 23.720 [11] to support non-IP data.  
Figure 2: NB-IoT architecture.