Page 34 - Methodology for inter-operator and cross-border P2P money transfers

• If for some reasons a transaction should (avoiding texts used to describe A or B-Par-
be ignored (e.g., because during data ty situations as defined above), or can be
entry wrong actions have occurred, or defined to flow a set of terms agreed in the
for other reasons), a short text describ- specific campaign. In any case, the text shall
ing the cause should be entered in the be suitable to clearly mark transactions which
Comment field, and Discard being tapped. need to be excluded from post processing.
The wording can either be freely chosen

15 MEASUREMENTS IN THE BACKGROUND

While staying within the general conceptual frame For convenience of reading, Table 6 of said Recom-
of ITU-T Recommendation P.1502, the context of mendation is repeated here to show in which cases
multi-network or cross-border testing require some the local mobile network performance has an effect
differentiation and careful consideration of respec- of DFS QoS:
tive conditions.

Well-performing DFS functionality Poorly performing DFS functionality
Well-performing mobile network High level of overall QoE, only vulner- Mobile network performance not rele-
able to local or temporal impairments vant/not visible
of each component
Poorly performing mobile network Overall DFS QoE strongly depends on Low level of overall QoE, no clear
mobile network performance dominance of each component

Background testing typically uses a mix of test cases • Fixed-size HTTP upload with moderate content
which are considered to be relevant for the DFS-re- size (e.g., 1 Mbyte), and generous time-out/pause
lated performance of the mobile network used for values
the DFS use case, i.e., in the current context, pack- • Web browsing with a rather lightweight standard-
et-data service performance. ized reference page, e.g., ETSI Kepler Smartphone
In the case of inter-operator and cross-border opera-
tion, based on the general principle that the scenario USSD and SMS elements can be added or omitted,
should be the same for all teams, the following guid- based on the assessment of the FTL). USSD can
ing rules apply: be problematic because a uniform set-up across
all teams would need USSD codes which fulfil the
• The network load caused by background-testing requirements of P.1502 for a multitude of countries.
should be moderate. In the case of SMS, the set-up of devices would be
• There should be no country-specific elements; it considerably more complex due to requirements by
follows that e.g., web browsing should use stan- the Android operating system. If USSD or SMS are not
dardized reference pages only, or live pages which primary for the implementation of the DFS service
can reason ably assumed to be general enough. (also in case of SMS, the use case itself provides
information about relative SMS performance), it is
This leads to the following recommended scenario: recommended to leave them out of the scenario.

• Fixed-size HTTP download with moderate content
size (e.g., 3 Mbyte), and generous time-out/pause
values

32 Methodology for inter-operator and cross-border P2P money transfers