 to validate the new feature. In the absence of a real NE, development features get validated against simulated NEs, with simulated interfaces and multiple assumptions about the feature and technology (where the specifications are not precise or leave room for interpretation). Hence, there are bound to be integration issues when the commercial UEs do become available. In cases where cooperation agreements between network development and UE vendors exist, such issues possibly get addressed better in extended integration testing. In most cases though, this implies issues when multiple commercial UEs diverge in their implementation or interpretation of standards. As a corollary to the above, where there are debug versions of UEs released, to help testing of other NEs, like eNodeBs, support may not be available for new features that are needed. Where there are commercial UEs available for testing, they may not provide enough debugging or logging capabilities to be of use during feature development and debugging. CHAPTER 3 DEPLOYMENT CHALLENGES IN EVOLVING 4G Feature Availability As discussed in the previous section, when all NEs are under development, planning integration testing and the rollout of a feature could be very difficult tasks. It could be that the standardization plans for the feature are made available for some projected period, requiring the network and UE vendors to commit to some date based on the same, so operators, in turn, could plan appropriate times for integration and field testing and deployment of the feature and a subscriber can be informed about the usage of such a feature and how it could benefit them in achieving their personal or business goals. Now, as always happens, Murphy's law could kick in, the best laid plans could go astray and delays could get introduced in all these processes. Essentially, the above process is like hitting a moving target and, depending on how much of a float is planned, the operator could absorb some of the delays. Being part of such a complex ecosystem inheren