One should not operate the network blind. Many of us have seen where such a behavior most likely ends up. On the other hand, some of us already know what it takes to achieve the exact opposite, I.e. to be sitting on the driver’s seat from day 1; one simply needs to do first things first.
Already many networks today are being actively and continuously monitored for their quality and throughput. But the thing that is many times overlooked and missing is the service activation testing. Service activation testing, as the name says, is best to be done right after the service has first been provisioned, and before the service is handed-over for production or end user. It is of course possible to add such a capability to your network also later, in case it is not yet available there for your engineering, quality, and customer services teams.
The Y.1564 ITU-T recommendation is a predecessor of the earlier RFC2544 specification by IETF. Whereas the main goal in RFC2544 testing has been to find the greatest throughput for any tested packet size between the tested end points, Y.1564 testing has a clear service focus to test the provisioned service as whole. This includes verifying that all the different traffic class flows, which together form the actual service, work together and each according to their individually defined requirements, throughout the entire network, exactly as intended.
Generally, as of today Y.1564 has gained more actual testing popularity among operators and service providers thanks to its service-oriented nature, albeit RFC 2544 is also still being requested in many RFQs.
Better rate of successful deployments
It just makes the best sense to do the first things first and in the scope of network quality testing this means that service bring-up validation should be the very next step after the service has first been provisioned. Service Activation Testing, or SAT in short, gives you the certainty that you are delivering exactly what was promised, and that you are not in a likely risk of having to start a troubleshooting drill any time soon after the service has been handed over. In short, this small and quick step gives you a better rate of successful deployments, as you will know for sure what has been delivered.
Build trust and confidence
As a tangible outcome of SAT testing is typically a test report, which we could simply call a birth certificate for the newly provisioned service. This certificate can be handed over to the customer up front as a proof that service works as promised, and that it indeed fulfils the agreed SLA, if such was agreed.
Typical deployments of Y.1564 SAT testing also allow for testing of a free mix of multiple different traffic flows with their individual QoS parameters, thus allowing to test the service as whole. Examples include testing of Data, Voice, and Conferencing services in parallel, which all service types have their own requirements in terms of maximum allowed values of packet loss, latency and jitter, marking the thresholds after which end customer would start to feel that a given service is no longer working on a satisfactory level. Making SAT testing a standard part of your service delivery process will help you build trust and confidence and to have happier customers and less churn.
Efficient and effortless troubleshooting
The same birth certificate serves also as an easy base reference, in case there is a suspicion later about service degradation and / or historical behavior. In such cases, birth certificate results can be easily compared to current performance of a given service and traffic flow, and it will be effortless to determine if service levels are indeed degraded and identify the root-cause of the degradation.
Typically, the historical records are stored in a centralized management system from which they are easy to re-run, utilizing any available test head in the system as test initiators. This approach compares favorably to the earlier era where handheld test equipment was still the norm and they were carried around by site engineers and test configurations had to be manually inserted every time. Today, all it takes is to simply re-run a past test case with all its original settings and then compare the results of the two tests. This way Y.1564 testing also becomes an efficient troubleshooting aid, which can save a lot of time and effort in a possible troubleshooting drill in the operational phase. Having done this simple operational phase validation step, you will instantaneously know whether you need to continue to investigate your part of the service delivery chain, or whether the reported problem is somewhere else.
Interested to learn more?