# mIoT Slice for 5G Systems: Design and Performance Evaluation
## 4 Introducing mIoT in 5G Systems
### 5 GS mIoT Slice Design
It worth noting the proposed solution, once standardized, would allow a seamless deployment of mIoT slices within any early real 5G system. Assuming a reasonable reference scenario where a Release 15 compliant 5G System has been set up (to provide eMBB service) via the deployment of NR access nodes connected to a 5 GC instantiated over general purpose cloud infrastructure, the deployment of an mIoT slice would substantially require three basic steps: first, a software upgrade of the access nodes which would be supposed to allow access of the mIoT devices, to support the aggregate core network bearer towards UPFs; second, a software update of the AMF, to enable the handling of the simplified mIoT CP procedures; and, finally, the deployment of mIoT specific SMF instances, dedicated to the handling of the UP for the related slice. Obviously, other 5 GC network functions would require configuration updates (e.g., the NRF and NEF, to allow the services provided by mIoT specific SMF to be accessible by other 5 GC NFs); these operational details, however, are out of the scope of this work, as not directly relating to architecture design. Similar steps would of course apply for the deployment of newly defined network slices. Standard compliant 5G mIoT devices, while accessing the network for registration, will provide the identifier of the mIoT slice they require service from (i.e., S-NSSAI (Single Network Slice Selection Assistance Information), as specified in [14]), this enabling the AMF to route CP signaling to the suitable SMF providing the coherent CP and UP handling. Operational details of the 5 GS mIoT network slice are illustrated in Figure 3. The description of the procedure on the access side is simplified for brevity, and as no major differences exist compared to 4G systems. Detailed description of Dteps 1 and 10 is included in [20] for 4G systems and in [24] for 5 GS. At the registration of the first PhD of a given device class, after successful authentication (Step 3), the context for a class C Virtual Device is created at AMF (Step 5) and a virtual address is allocated to the VD. Subsequently, the SMF establishes an ACN bearer between the UPF of the (R)AN the PhD accessed and all the UPFs required to route data to the external PDN (Step 7). At the registration of (up to U, where U can vary for each device class) further PhDs of the same class and accessing from the same (R)AN node, after successful authentication (Step 13), such devices are associated to the same VD (Steps 15-17) and their data will be transported from/to the PDN via the correspondent ACN bearer previously established. The SMF executes an update of the bearer, to ensure proper data routing for all PhDs. It should be noted a bearer update will require less CP resource compared to a bearer setup. Although different PhD addressing schemes will be envisioned (and they are out of scope of this work), it is assumed each mIoT data packet is associated to a source address and a destination address, and it is encapsulated into the SDU (service data unit) transported by the ACN bearer. For UL transmission, the virtual address of the VD is used to route packets generated from all PhDs to the PDN UPF Gateway; packets will be further forwarded within the external PDN based on the destination address of the packet generated by the PhDs. For DL transmission, incoming packets at PDN UPF Gateway associated to a VD can be routed to the appropriate (R)AN UPF node; the (R)AN node, however, requires additional information to identify the PhD the packet is directed to. To this end, the aggregate bearer SDUs will have to be tagged at PDN UPF Gateway according to the packet destination address; based on the tag, the (R)AN node will be enabled to address the proper physical device on the radio link. The ACN bearer update is needed to enable the tagging at PDN UPF Gateway and the tag identification at (R)AN.