Page 20 - Methodology for inter-operator and cross-border P2P money transfers
P. 20

time. Only then it is possible to create respective KPI   are required to assign measurement data to the right
            correctly.                                         context.
            For  instance,  assume  Team  1  and  2  are  running  a   Basically there are several types of electronic IDs:
            national test between two DFS providers, and at the
            same time, team 3 and 4 is running a cross-border   •  Fixed ID’s, such as IMEI or MAC addresses. In most
            test on another set of DFS providers. For a given    cases they can be read electronically by apps
            transaction for the national test, timer flags T1 to   through respective API’s. However, in recent years
            T6, are taken by team 1, while T7 is taken by team 2.   operating systems put restrictions on this type
            For the cross-border test, T1 to T6 is taken by team   of ID as they allow identification of devices and
            3 and T7 is taken by T7. Likewise, network perfor-   therefore – in case where devices are also used for
            mance tests are also collected by respective devices   personal purposes – may create privacy issues.
            in different locations.                            •  Dynamic ID’s which are created with every new
            Assuming that all data is imported to the same data-  installation and which are not lined to any static
            base – which is the usual way to process data for    attributes or properties of the platform.
            best efficiency – allocation of respective device ID
            to DFS service test scenarios has to be made, which   In any case, suitable ID’s need to be unique, i.e., it
            requires corresponding information about measure-  must  be  made  sure  that  no  two  devices  or  rather,
            ment system allocation and testing schedules. Also,   data sources, have the same ID to prevent mix-up
            the process of data cleansing – removing of data   data assignments.
            which is considered to be not valid – requires respec-  In the current case, it is assumed that devices are
            tive information.                                  sourced exclusively for testing purposes, so fixed ID’s
            In many cases, it may be possible to deduct informa-  are not problematic. The MSW provides, however,
            tion which identifies the scenario under test by using   dynamic ID generation and is therefore more versa-
            information  in the primary data  source,  e.g.,  GPS   tile.
            locations in the background-testing data. However,   There are two central lists, maintained by the Field
            as the methodology is supposed to work in a robust   Test Lead (FTL) in co-operation with the entity
            way under a wide range of conditions, it cannot    managing the overall testing activities:
            be guaranteed that these information sources will
            always have sufficient information. For instance, if   •  The Device Assignment List (DAL) holds informa-
            tests are done from within a building, a valid GPS   tion about the assignment of devices and tool app
            position fix may not be available. Therefore, frame or   ID’s to teams.
            top-level information should be provided.          •  The Team Assignment List (TAL) is holds infor-
            Basically, such frame information can be provided    mation about the time schedule of scenarios and
            centrally or locally. As such tests are typically done   respective team pairings (under the assumption
            in  a  planned  manner  with  a  central  management   that each team runs one end of a two-way MoMo
            entity, there should be a register of team, device,   use case as defined in the Transaction Model).
            and scenario allocations versus time. For maximum    The TAL is used both for planning activities, as for
            robustness, it is recommended  to also collect this   documenting them afterwards.
            information again locally, i.e., using log sheets list-
            ing what has actually been done by the teams. As   Important note: If team assignments change, it is
            this information is typically high-level, i.e., taken only   especially important to keep good record of these
            once per location or testing session, load on teams is   assignments, to prevent data loss or artefacts due to
            low and the extra redundancy improves the overall   unclear or incorrect combination of data from differ-
            robustness of testing.                             ent teams/data sources.
            This methodology is designed to be robust in the   Copies of the DAL and TAL are imported to the
            sense that a certain degree of redundancy is main-  post-processing database and serve as the source of
            tained for information which is essential to proper   assignment operations required to generate KPI and
            data evaluation. The most essential information is   other report information.
            which teams are paired for a given test case, and   In addition, each team uses log sheets (in paper or
            about the assignment of electronic ID’s of respective   electronic  form) to  document their  activities  local-
            tool installations.                                ly. These log sheets provide an additional layer of
            These  electronic  ID’s  are  the  most  essential  single   robustness by providing redundancy of information
            elements of a test and measurement set-up, as they   with respect to central lists.



            18   Methodology for inter-operator and cross-border P2P money transfers
   15   16   17   18   19   20   21   22   23   24   25