|
4G/LTE - IP Allocation |
|||||||||||||||||||||||||||||||||||||||||||||
|
IP Testing (IP Allocation/Setup Testing)
What pops up in your mind when you hear about 'IP Testing' ? Some body may think about Throughput Testing, somebody think about Browsing and some others would think of IMS /RCS kind of testing. Yes, they are all based on IP layer and each of them has very long story of their own. I have completely separate pages of the topics like throughput and IMS. In this page, I will talk about rather fundamental, probably the most fundamental and critical for any IP related functionality. I will talk about testing 'IP allocation' or 'IP establishment'.
Many people take this step as granted and when they get a device (UE) for a test, they tend to assume that this process will be done automatically in any situation and they don't have to care about it, but it is COMPLETELY WRONG assumption.
You would see (or already has expienced) a lot of cases where the problem happens at this IP assignement (data path establishment) step even before you think about higher layer application like ftp software or IMS stack etc.
To make things even worse, if some problem happens at this step, the troubleshooting is not that simple. Why ? Following illustration shows my personal impression (based on many years of experience) on why IP/Application layer testing/troubleshooting is more difficult comparing to other lower layer testing.
Why testing and troubleshooting at this stage is so difficult ? I don't know if you might have noticed it from the illustration above or not. It is not because it is like rocket science (requiring a lot of physics, math and all different kind of high end engineering technique) but because most people just start testing without clear definition of test requirement and procedure. It may sound funny but they just trying testing without clearly understanding what to test. As indicated in the illustration above, so many different variation of implimentation is allowed but no single UE implements all those possible variation. Usually a specific UE implements only a specific subset of all the possible variation. So if a UE implements based on a subset 'A' and the test case specification is described based on subset 'B'. The UE would fail in the test. It is not because UE implementation is wrong. It is not because the test case description is wrong. It is because UE implementation and test case requirement doesn't match. Another serious problem (I think this is even more serious). Not so many testers are fully informed about exact UE implementation and what is capable and what is not capable. In most case, I saw there are very wide barrier between testing people and IP stack developers. They were just given a device and asked to test without the detailed information. So it is likely that the testing people would try to test the device based on wrong test condition (test spec).
My suggestion is to make a check list as in detail as possible and check if you have the answers to all the items in the list and check if the test case document specifies about all the check items before you start testing. If you are missing with any of the check items required for a specific test, then the troubleshooting would be more like random try and error, or just blackbox analysis. You would get it work or not purely based on how lucky you are. It is nothing to do with your engineering skill or intelligence.
In this page, I will start out creating some check list and this list would get longer. (This is the check list only for basic IP setup, there would be another long list of check list if you go with any specific application. For example, you can get another long list of check items here if you do IMS related testing)
Once you got the answers to all the items in the checklist, you can define a list of UE requirement for the test you want to perform. What I am going to do in this section is to present some of the possible examples of UE requirement. These are just examples to give you an idea. You may not be able to get the real UE in the market that exactly matches these examples.
: This is a UE that is at the top of my wish list. If you have a UE like this, you may be able to do the most of IP related test (except IMS/RCS since I didn't put any requirement on this application) in any combination of IP type. You may be able to have this kind of UE if you are working at a UE maker and get the test UE at development stage, but it would be hard to get the UE with this kind of flexibility from mobile shop. Usually when a UE maker release (commericialize) a UE in the market, they tend to customize (in most case restrict the flexibility) the available feature set requested by a specific network operator and block many of the features that is not required by the specific network operator. i) UE shall allow user to create their own APN for testing. ii) UE shall allow to set APN type as any IP type (IPv4, IPv6, IPv4v6) iii) UE shall allow any APN name for the test iv) UE shall be able to support at least 2 PDN v) UE shall provide a tool to display all the IP address assigned to it vi) UE shall provide a tool to run 'ping' from UE vii) When a PDN is set to be IPv4v6, UE should send DNS query to both IPv4 and IPv6 DNS Server if NW provided both DNS address. viii) UE shall allow any Test USIM at least up to IP establishment (UE may require a specific USIM for IMS/RCS) ix) UE shall accept any APN name Network assigns in Activate Default EPS Bearer Context Request
: I think this would be more practical requirement and you might have seen this kind of requirement from many of the test case description.
i) UE shall have the predefined two APN as follows ii) UE shall provide a tool to display all the IP address assigned to it iii) UE shall allow any Test USIM at least up to IP establishment (UE may require a specific USIM for IMS/RCS) iv) UE shall NOT detach IPv6 APN even though IMS Registration is not successful.
Note : Many of the test case does not specify about item iv) and a lot of UEs shows different behavior causing a lot of confusion and a lot of difficulties with troubleshooting
In this section, I will give you some examples of possible test cases. I will start out with some test cases for initialization of IP address (and data path) and then add test cases with application and service layer test case.
TC-Case 1 : IPv4 only PDN and Single PDN>
i) Setup Test Equipment with the Parameter Setting XYZ ii) Power on UE and let UE initiate the attach process for the network. iii) Verify UE send PDN Connectivity Request (piggybacked in RRC Connection Setup Complete) with the following IEs iv) Verify Network send Activate Default EPS Bearer Context Reqest with following IEs v) Complete Attach/Registration Process vi)Verify UE assigned following IP address to itself
TC-Case 2 : IPv6 only PDN and Single PDN>
i) Setup Test Equipment with the Parameter Setting XYZ ii) Power on UE and let UE initiate the attach process for the network. iii) Verify UE send PDN Connectivity Request (piggybacked in RRC Connection Setup Complete) with the following IEs iv) Verify Network send Activate Default EPS Bearer Context Reqest with following IEs v) Complete Attach/Registration Process vi) UE send Router Solicitation vii) Network send Router Advertisement viii) Verify UE assigned following IP address to itself
TC-Case 3 : IPv4v6 PDN and Single PDN>
i) Setup Test Equipment with the Parameter Setting XYZ ii) Power on UE and let UE initiate the attach process for the network. iii) Verify UE send PDN Connectivity Request (piggybacked in RRC Connection Setup Complete) with the following IEs iv) Verify Network send Activate Default EPS Bearer Context Reqest with following IEs v) Complete Attach/Registration Process vi) UE send Router Solicitation vii) Network send Router Advertisement viii) Verify UE assigned following IP address to itself IPv4 IPv6
TC-Case 4 : IPv6 and RA Failure >
i) Setup Test Equipment with the Parameter Setting XYZ ii) Power on UE and let UE initiate the attach process for the network. iii) Verify UE send PDN Connectivity Request (piggybacked in RRC Connection Setup Complete) with the following IEs iv) Verify Network send Activate Default EPS Bearer Context Reqest with following IEs v) Complete Attach/Registration Process vi) follow the steps (3)~(6) as shown below.
TC-Case 5 : IPv4v6 and RA Failure >
i) Setup Test Equipment with the Parameter Setting XYZ ii) Power on UE and let UE initiate the attach process for the network. iii) Verify UE send PDN Connectivity Request (piggybacked in RRC Connection Setup Complete) with the following IEs iv) Verify Network send Activate Default EPS Bearer Context Reqest with following IEs v) Complete Attach/Registration Process vi) follow the steps (3)~(6) as shown below.
|
|||||||||||||||||||||||||||||||||||||||||||||
