tree c10ee45dc34fbddaaa5c44720650d3058ff5b231
parent b34f5a9c378bebaf963b87cca561fc734c8d2170
author Pau Espin Pedrol <pespin@sysmocom.de> 1664798274 +0200
committer Pau Espin Pedrol <pespin@sysmocom.de> 1664798402 +0200

ggsn: Fix TC_gy_charging_volume_quota_threshold expectations

in Diameter, the CC-Input/Output direction is defined as follows in
RFC4006:
"""
8.24.  CC-Input-Octets AVP

The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and
contains the number of requested, granted, or used octets that can
be/have been received from the end user.

8.25.  CC-Output-Octets AVP

The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and
contains the number of requested, granted, or used octets that can
be/have been sent to the end user.
"""

So:
* 3GPP uplink is from end user to PGW, and hence 'CC-Input-Octets'
* 3GPP downlink is to end user to PGW, and hence 'CC-Output-Octets'

This test started failing a few days ago since a bug was recently
fixed in open5gs which was swapping the counters in open5gs-upfd:
https://github.com/open5gs/open5gs/pull/1793
https://github.com/open5gs/open5gs/commit/f72a1edc6ed35cf5289243d660a73beb0a99e312

Change-Id: I2f64649ce70d85634f14b84eff98731f7711cbad