## 3 Technical Background on SCHC and Cellular IoT
### SCHC over NB-IoT  
RFC 9391 [31] defines the application of SCHC on NB-IoT with three possible use cases. In the first use case, SCHC is used over the radio link. This would require placing SCHC as part of the protocol stack for data transfer at the end device and the base station (i.e., eNB). The 3 GPP architecture already supports Robust Header Compression (ROHC) [40]. As such, SCHC can be deployed within a similar architecture without the need for an important change.  
The second use case suggests that SCHC is used over the Non-Access Stratum (NAS). In NB-IoT, the end device can use the preestablished security and piggyback small uplink data into the initial uplink message. This transmission is known as Data over Non-Access Stratum (DoNAS) or Control Plane Ciot EPS optimizations. In contrast to the first use case, SCHC is placed within the Non-Access Stratum (NAS) protocol layer. From a network perspective, SCHC would be implemented in the network's core (Mobility Management Entity) instead of the eNB (base station), as in the first use case.  
In the third use case, SCHC functionalities are implemented in the application layer of the device and the application server or a broker function at the edge of the network. The packets are delivered between the packet gateway and the application server or between the Service Capability Exposure Function (SCEF) and the application server, using IP tunnels or API calls. More information on the SCEF and API architecture can be found in Section 4.4. The compression is applied before the transmission in both cases. The network  
\begin{table}
\begin{tabular}{c c c c c c c} \hline
**FID** & **FL (bits)** & **FP** & **DI** & **TV** & **MO** & **CDA** \\ \hline IPv6 Version & 4 & 1 & Bi & 6 & equal & not sent \\ \hline IPv6 Diffserv & 8 & 1 & Bi & 0 & equal & not sent \\ \hline IPv6 Flow Label & 20 & 1 & Bi & 0 & equal & not sent \\ \hline IPv6 Length & 16 & 1 & Bi & – & ignore & compute \\ \hline IPv6 Next Header & 8 & 1 & Bi & 17 & equal & not sent \\ \hline \(\mid\) IPv6 Hop Limit & 8 & 1 & Up & 255 & ignore & not sent \\ \hline \(\mid\) IPv6 Hop Limit & 8 & 1 & Dw & – & ignore & value-sent \\ \hline IPv6 DevPrefix & 64 & 1 & Bi & alpha/64 & equal & not sent \\ \hline IPv6 DevIID & 64 & 1 & Bi & – & ignore & DevIID \\ \hline IPv6 AppPrefix & 64 & 1 & Bi & gamma/64 & equal & not sent \\ \hline IPv6 AppIID & 64 & 1 & Bi & \(\pm\):1000 & equal & not sent \\ \hline UDP DevPort & 16 & 1 & Bi & 8720 & MSB(12) & LSB \\ \hline UDP AppPort & 16 & 1 & Bi & 8720 & MSB(12) & LSB \\ \hline UDP Length & 16 & 1 & Bi & – & ignore & compute \\ \hline UDP checksum & 16 & 1 & Bi & – & ignore & compute \\ \hline \end{tabular}
\end{table}
Table 2: Example of compression rule for IPv6/UDP. Dev: device; App: application; Bi: bidirectional; Up: uplink; Dw: downlink; MSB: most significant bytes; LSB: least significant bytes [37].  
will treat the packet as normal traffic and deliver it to the other side without any special action. This use case is particularly interesting and will be considered in this work as it does not require any changes in the existing 3 GPP specifications and can provide an additional level of interoperability by enabling IPs over non-IP Data Delivery (NIDD).  
SCHC is implemented as a software at the device level requiring no additional investment in terms of hardware or components. On the network side, a SCHC server is required at the edge of the network, still not changing anything in the existing deployments or specifications.