### The main point You may ask, “What’s the point of usage guidelines, anyway?” The wireless network operates differently than traditional wireline networks. The Radio Access Network or RAN is a shared resource, serving a finite number of users at a given time. The guidelines are written in order to help users, application developers, and device manufacturers—especially those that are not used to operating in a shared network—to understand how to operate efficiently in this environment. ### How often to connect to the network - Automated RF access attempts, for both mobile originations and terminations, should be limited to 4 per hour. In certain circumstances devices and applications may connect more frequently (see full document for details). - VPN tunnels and IP SLA probes on wireless devices should not be configured with keep-alive timers that run at intervals of less than 5 minutes. - For routers, the cumulative number of keep-alive/hello transmissions should not exceed 1 keep-alive/hello per 5 minutes. The Dynamic Mobile Network Routing (DMNR) feature (a.k.a. NEMO) is the alternative to using overlay tunneling and IGP/BGP routing protocols. - Category 1/M1 devices have more opportunity for efficient operation with the use of new 3GPP features PSM and eDRX which enable longer device battery life while reducing newtork connection frequency. ### Improve connection efficiency - Applications should be optimized to reduce the number of network access attempts by initiating polling only when relevant data events occur. - Applications should release the RF resource (radio connection) within 5 seconds of the last byte of data. - Establish event triggers in the device application as criteria for establishing a data session. ### Special network situations - When devices experience connectivity issues, applications should retry network access using Data Retry Guidelines back-off intervals. - In the event of a network or server outage, devices within the same cell sector should restore/register with the network in a staggered manner. ### Abnormal disconnects Abnormal disconnects occur when a device disconnects from the network for any of the reasons stated in the table below. This informs you if a device was disconnected unexpectedly due to an issue. ThingSpace receives the disconnect reason from the network and in turn notifies you when that happens, assuming you have the alert rule for this enabled. | Abornomal Disconnect Code Description | Code Value | | ------------------------------------- | ---------- | | Lost-Carrier | 2 | | Lost-Service | 3 | | Port-Error | 8 | | NAS-Error | 9 | | NAS-Reboot | 11 | | User-Error | 17 | | Suplicant-Restart | 19 | | Reauthentication-Failure | 20 | | Port-Reinitialized | 21 | | Port-Administratively-Disabled | 22 | **See your Verizon Solutions Architect or Solutions Engineer for the complete set of guidelines entitled “Application, Device and Network Usage Guidelines for IoT.”**