Just when you thought you were working with a standard
When I was working with a large swap out charging system recently, we have to integrate to an existing 3rd party vendor's (Nokia Siemens Network) product. The protocol used by the 3rd party is diameter (RFC 6733). "That would be easy peasy piece of job" as some would think that since we were swapping out the existing 3rd party product, all that is required is to change existing clients to point to the replaced Ericsson charging nodes since both products (the Ericsson's product and 3PP product) publish to the same protocol standard. The myth is crashed because although like all standards, there are also slight variations to the standard as each vendor designed their interface differently to take advantage of their system features.
Recognizing the differences between the two standards is one of my key task as I have to educate our partner vendor to perform the necessary mapping transformation from NSN's protocol to Ericsson's protocol (SCAPv2). NSN uses Service-Information (AVP code 873) to package her user-defined charging information while Ericsson achieves the same through the Service-Parameter-Info (AVP code 607). Internet provides my initial source of information but I have to resort on cramming on the two products documentation to come out with the right mapping.Seagull - an essential SI tool
The other challenge that the team faced is how to perform functional tests on the NSN diameter protocol. Although there is an Ericsson simulation tool, I was getting no joy from internal Ericsson's experts who have advised me that the effort required to get the tool up and running may be significant. The initial path adopted by the team is to capture the protocol on several use cases and played back the captured protocol to simulate the use cases.I soon realized the short falls of this technique as it was a slow discovery process to uncover new bugs. The game is on to look for a new functional testing tool. After the evaluations of several candidates, I settled on using an open source multi-protocol traffic generator, Seagull.
There are no internal experts to consult and the brief Seagull documentation details is of not much help neither. I have to resort to reverse engineer the protocol from other sources. I used another open-source tool; this time wireshark (formerly known as ethereal). Creating the NSN diameter dictionary file was the first step.
The next stage would be to design the scenario files. A scenario file describes the messages that were exchanged during traffic. In Seagull, you create one scenario file per use case. The scenario file contains two key sections; the <init> section and the <traffic> section. In the <init> section, you specify the CER command sent and the expected command received (normally CEA) during the initialization stage. In the <traffic> section, you specify your CCR command that you would be sending and the expected CCA command to receive. The actual CCR and CCA differs in each use case and the protocol is specific to how the backend charging system supports the charging function.ECUR and IEC
Creating a generic tool makes the learning more effective. The tool that I have developed is a testing suite to test the functions of the business requirements of the actual project. To make the tool flexible to test all possible test factors (e.g. the user phone number, the product id, the plan code, the amount to be charged, the session id), I extended Seagull by creating parameterized variables to replace the parameters during run time.
The testing suite supports both types of charging :-
- ECUR (Session based charging)
- IEC (Event based charging)
It allows testing engineers to perform the following functional tests
ECUR Functional Tests
- Reserve payment
- Commit (after a reserved is made)
- Cancel of a reservation
- Get transaction status
IEC Functional Tests
- Direct debit
- Get subscriber’s wallet details
- Activate a subscriber via MMS
Questions for assessment purpose
Building this testing suite allowed me to gain in-depth knowledge of Seagull to create an effective training session to Ericsson's testing team. Designing the materials there after becomes an easy task. The final stage of designing the training session is to create questions for assessment purpose. To make the learning more valuable to the engineers, I have further customized some of the questions specifically for the client environment. Relating the questions to the client environment thus become a "relatable experience" to the students and make the learning more effective. Here is a sample of the questions that I have designed for this training:-
- Which protocol does SEAGULL use to test the IL charging gateway?
- Which one of the following is not a valid DIAMETER message?
- Which tool do you use to perform your snoop?
- What does CCN use to decide on a unique peer?
- Which DIAMETER message is missing in your snoop if you do not see any deduction?
- What is a session based charging?
- What is a default timeout for a session based charging?
- In which state of the subscriber can you perform a deduction?
- If the subscriber is in a PRE-ACTIVE state, which type of DIAMETER operation will be successful?
- What is EPOCH?
- Which field associates a “Reserved Payment” operation and a “Get Transaction status” operation?
- What is the easiest way to verify if a payment has been reserved?
- Which of the following is a ECUR operation?
- If you perform a deduction using plan code BD5, how much will be deducted from the AIR TIME balance?
- What is the Result-Code when you try to perform a “Direct Debit” on a PRE-ACTIVE subscriber?
- What is the Result-Code when you try to perform a “Direct Debit” on subscriber who has insufficient balance?
- What is the Result-Code when you try to perform a “Commit Payment” if you have not performed a reserved payment?
- What is the Result-Code when you perform a “Get Balance” query on a subscriber with insufficient balance?
- Which of the following is an IEC operation?
No comments:
Post a Comment