 the call. Timers of some kind are present in most network functions, but the ones that are most important for call setup are present in the Next-Generation NodeB (gNB) and Access and Mobility Management Function (AMF). These timers determine the time needed for the completion of procedures such as PDU setup and SO on. The expiry of these timers can cause a retry or complete process failure. It is, therefore, a good idea to plan the timer duration SO that all the timers in the network are consistent with each other. A rule of thumb, although not written in stone, is to plan the timers such that the value increases as we move from the RAN to the core, component by component. The timers that are related to the setup of the entire call should consider the end-to-end latency and round-trip time. Functional testing: This is done when the software is already checked for sanity and is ready for prime time. The individual network function software is installed and integrated with one or two interfacing network functions, and the rest of the components are simulated. The reason for integrating a few network functions at a time is to eliminate the chances of too many unknowns. If you choose to integrate all the network components in one go, then it could be very hard to debug as the call would touch too many network functions, and a failure reason or faulty configuration could be hard and time-consuming to detect. Hence, it is a good idea to start small and grow to cover the whole network. This will result in better debuggability and a faster testing cycle. Identifying use cases: It is a good idea to identify the scenarios and use cases that the network will need to support once the functional testing is complete and all the network functions have been integrated. This is the time to test the end-to-end use cases. Some examples are voice calls and video calls, traffic streaming, and sending MMS messages. Running continuous calls to test performance and longevity: Once the network is tested functionally and integrated, it i