As illustrated in Figure 5.1.2.1.1, the CDF - CGF communications are carried out using GTP' over UDP/TCP and IP.

If necessary, CGF to CGF communications are carried out using GTP' over UDP/TCP and IP. This is illustrated in Figure 5.1.2.2.1.

The following example cases represent the three different key "Data Record Transfer Request/Response" messaging related CDR handling schemes. Cases (2) and (3) represent situations involving the redundancy mechanism.

1. The normal CDR packet transfer:
   The CDF sends successfully a CDR packet to the CGF, and since the CDF gets a response (Request Accepted) for the Data Record Transfer Request, there is no need to use the CGF redundancy mechanism and redirect the CDR packet traffic flow to another CGF.
2. The CDF-CGF connection breaks before a successful CDR reception:
   In this case the CDR packet sent by the CDF is lost before it is received by the CGF. (The loss might be caused by a link failure or e.g. a major CGF failure.)
3. The CDF-CGF connection breaks after a successful CDR reception:
   In this case the CDR sent by the CDF is received correctly by the CGF and moved to its non-volatile memory
   (or even to the next NE in the communication chain). Anyhow, the CDF-CGF communication stops working, in this example case, before the CDF gets the positive response (Data Record Transfer Response: Request Accepted)
   which would acknowledge that the CDR packet was successfully received by CGF.
4. CGF redundancy mechanism
   An overview on the mechanism, involved in cases (2) and (3), preventing duplicated CDR packets to enter a BD.
   The next four clauses describe in more detail each of these key "Data Record Transfer Request / Response" messaging schemes.

Figure 5.2.2.1.1 shows the default mode of CDR transfer from the CDR generating functions (CDFs) to the CDR collecting functions (CGFs).

The general principle of GTP' to retransmit the request if the response has not been received within a configurable time-out limit, is also followed here in point 1). The maximum amount of retries is a configurable value.

Figure 5.2.2.2.1 shows the exceptional case when the CDR transfer from a CDR generating entity (CDF) to the primary CDR packet collecting entity (CGF1) fails in a way that the CGF1 is not able to store the CDR packet sent by the CDF. (The reason for the failure in packet transfer may be e.g. a link failure between the CDF and CGF1, or a capacity exhausting error in the storage device of CGF1, or a general CGF1 system failure or CGF1 maintenance break.)

After all the potentially duplicated packets are cleared from CGF(s), the CDF can continue in normal way the transfer of CDRs.

After all the potentially duplicated packets are cleared form CGF(s), the CDF can continue in normal way the transfer of CDRs.

A summary of the CGF redundancy mechanism, which prevents duplicated CDR packets to enter the BS, is described below. This, or other mechanisms, are deployed to enhance the reliability of CDR transport. The general logic of the duplicate CDR packet prevention in CGF redundancy cases is shown in Figure 5.2.2.4.1, where the messages are numbered sequentially, alternative messages are indicated by an index character ("a" or "b") that follows the arrow sequence number. The main mechanism of the messaging in CGF redundancy cases (when a CDF-CGF link is down or a CGF is not working) is based on CDF (1) first trying to send a CDR packet to CGF1. In case no acknowledgement or a successful response is received (2) from CGF1 due to any reason, e.g. such as the request not reaching CGF1 despite repeated attempts (or the responses from CGF1 to the CDF are lost after the CGF1 has either stored it securely, or, forwarded it towards post-processing (2b)), the unacknowledged CDR packets are redirected to CGF2. The invocation for a re-transmission may be triggered by a time-out mechanism. The CDF may first test the CDF-CGF2 link by sending an 'Echo Request' message to CGF2, in response to which CGF2 would respond with the 'Echo Response' message. The CDR packets not successfully received by the primary CGF (=CGF1) are sent to CGF2 (3), and are marked as potential duplicates, and CGF2 responds to the request(s) (4). Such CDRs, i.e. CDRs that are marked as potential duplicates would wait there for further commands from CDF. When the CDF detects (5) and (6) that the primary CGF, in this case CGF1 is again able to communicate with it on receiving Node Alive Request (or getting a Echo Response from CGF2 to a Echo Request sent by the CDF) it answers by Node Alive Response. Then the CDF tests CGF1 with an empty packet (7), retrying continuously if no response is received, using e.g. increasing timeouts (using the old unacknowledged packet's Sequence Number, if the CGF1 would consider the packet to be a new one (8a) or an already received one (8b)). According to the response received from CGF1, the CDF gives the CGF2 a command to either release (9a) or cancel (9b) the corresponding CDR packet from CGF2. CGF2 then confirms the decision (10), and is able to send the CDRs towards the BS (11a). Error handling:

A more detailed description of the CGF redundancy mechanism: Sequence number buffers: The CDF is able to instruct CGF2 to cancel (or instruct CGF2 to transfer towards the BS), the CDR packets sent to a secondary CGF if the primary CGF becomes available for service. To make the right decision the CDF first sends an empty test packet with the 'Send possibly duplicated Data Record Packet' Packet Transfer Command to the primary CGF, using a previously not responded Sequence Number. In case that the empty test packet to the primary CGF (which was temporarily down (or to which the link was down)) is responded with the Cause value "Request Accepted", the CDF releases the corresponding CDRs waiting for final decision in the secondary CGF, towards the BD with the Packet Transfer Command "Release Data Record Packet". If the primary CGF responses this test message with the Cause value "Request related to possibly duplicated packets already fulfilled", the CDF cancels the corresponding CDRs waiting for final decision in the secondary CGF, using the Packet Transfer Command "Cancel Data Record Packet". To enable that a CDF failure (destroying its Sequence Number buffers per each CGF link for non-responded requests or possibly duplicated packets) would not cause CDR packets to stay forever in the temporary decision waiting buffers of CGFs, there should also be OAM&P means of emptying those CGF buffers. There shall also be a configurable parameter in the CGF for making the final decision, as to whether or not it is able to send the CDRs to the BS for the case where the backup buffering mechanism in the CDF could not be used until the end of the messaging sequence related to a certain CDR packet has been completed. This way the operator can:

1. Select that the CDFs and CGFs take care of duplicate prevention and the BS is not required to do duplicate checking due to possible duplicates caused by Network Element or CGF redundancy mechanisms.
2. Select that the BS performs the duplicate prevention. To do this in the most effective way, the CGF may include an additional flag linked to possibly duplicated CDRs sent to the BS, indicating that they have not been released by a CDF for BS use (or use special kind of file name if a file protocol is used between CGF and BS). This means that the BS has somewhat more processing work to do, but the BS would anyway get a duplicate free end result. CGF is in this case always authorized to forward CDRs towards the BS, also when they contain possibly duplicated data. For this case the CGFs may also have a configurable flag that Data Record Packet Cancel/Release operations are not needed.