# The file includes KPI formulas for MOs within Transport ECIM branch with prefixes Rtn & Rsync.
# The KPIs which are defined by section number x.y.z.w are based on document Transport Network Performance Indicators 5/0363-90/FCP 130 0532 Uen Rev C
# The general syntax for the formulas is a follows:
#  Tn_ObjectWhatDirectionModification_Unit or Cat_UnitObjectModification_Unit
#  where:
#    Tn - for all Transport related counters
#    Object - Ethernet, Vlan, Ip, IpSec, Sctp, Twamp, Ptp, etc
#    What - Throughput, Faults, Loss of Signal, Discards, Availability
#    Direction - In, Out
#    Modification - Avg, Max, Min, Success Rate, etc
#    Unit - Volt, Amp, mAmp, Ah, Watt, Wh, kWh, C, fps, Kbps, Mbps, Mbps, min, s, h, ns, ms, dB, dBm, RL (Return Loss), VSWR, PRB (Phy. Res. Blocks) Pct, etc a:b (Ratio), # (No of occurrences), #s-1 (occurrences per second)
#
#    Note that HC stands for High Capacity 64-bit Counters.
#
#The following KPI groups are used:
# Accessibility      Acc_    ERAB Setup Success Rate, RACH and Paging, etc.
# Availability       Av_     eg. system downtime (RBS Restart time measurements)
# Integrity          Int_    DL and UL throughput, packet loss, latency, packet delay, etc.
# Mobility           Mob_    eg. handover success rate
# Retainability      Ret_    eg. session drop rate
# Transport Network  Tn_
# Equipment          Cat_, Env_
# Utilization        Utl_    hw utilization, background CPU load, interface utilization, memory usage and Radio Utilization

# v 2.0 31/12/2024 T. Malkiewicz New revision to include KPIs for counters for Rtn.. & Rsync... MOM fragments for Baseband & CC6610
#--------------------------------------------------------------------------------------------------------------------------------


#################
##  Ethernet   ##
#################
# Majority of the counters for EthernetPort MOs are based on "The Interfaces Group MIB" RFC 2863, which defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.
# For detailed descriptions of the counters, refer to the RFC 2863 memo.
# Non standardized additions deal with LossOfSignal,  UnknownTags & OctetRatePercentiles.

# 3.1.2.1 Ethernet Ingress rate (FPS). \nThis PI monitors the number of ingress frames per second (fps) at the MS RBS per Ethernet interface. \nIt includes all types of Ethernet frames (both switched and routed) and frames dropped due to node congestion. Frames containing Ethernet level errors are not included in this PI. However frames dropped at high layers, for example IP TTL expire, are included. [fps]
Tn_EthernetThroughputIn_Fps = ( ifHCInUcastPkts + ifHCInBroadcastPkts + ifHCInMulticastPkts ) / ( 900 * NR_ROP)

# 3.1.2.2 This PI monitors the number of ingress bits per second (bps) at the MS RBS per Ethernet interface. \nIt includes all types of Ethernet frames (both switched and routed) and frames dropped due to node congestion. Frames containing Ethernet level errors are not included in this PI. However frames dropped at high layers, for example IP TTL, expire are included. [kbps]
Tn_EthernetThroughputIn_kbps = (ifHCInOctets * 8) / ( 900 * 1000 * NR_ROP)

# 3.1.2.2 This PI monitors the number of ingress bits per second (bps) at the MS RBS per Ethernet interface. \nIt includes all types of Ethernet frames (both switched and routed) and frames dropped due to node congestion. Frames containing Ethernet level errors are not included in this PI. However frames dropped at high layers, for example IP TTL, expire are included. [Mbps]
Tn_EthernetThroughputIn_Mbps = (ifHCInOctets * 8) / ( 900 * 1000000 * NR_ROP)

# 3.1.2.3 This PI monitors the number of egress frames per second (fps) leaving the MS RBS per Ethernet interface. \nIt includes all types of Ethernet frames (both switched and routed) and frames that are dropped due to node congestion. Frames containing Ethernet level errors are not included in this PI. However frames dropped at high layers, for example IP TTL expire, are included. [fps]
Tn_EthernetThroughputOut_Fps = (ifHCOutUcastPkts + ifHCOutBroadcastPkts + ifHCOutMulticastPkts - ifOutDiscards - ifOutErrors ) / (900 * NR_ROP)

# 3.1.1.4 This PI monitors the number of egress bits per second (bps) by MS RBS per Ethernet interface. \nIt includes all types of Ethernet frames (both switched and routed) and frames dropped due to node congestion. Frames containing Ethernet level errors are not included in this PI. However frames dropped at high layers, for example IP TTL expire, are included. [kbps]
Tn_EthernetThroughputOut_kbps = ( ifHCOutOctets * 8 ) / (900 * 1000 * NR_ROP)

# 3.1.1.4 This PI monitors the number of egress bits per second (bps) by MS RBS per Ethernet interface. \nIt includes all types of Ethernet frames (both switched and routed) and frames dropped due to node congestion. Frames containing Ethernet level errors are not included in this PI. However frames dropped at high layers, for example IP TTL expire, are included. [Mbps]
Tn_EthernetThroughputOut_Mbps = ( ifHCOutOctets * 8 ) / (900 * 1000000 * NR_ROP)

# 5.1.1.1 Ethernet Ingress Frame Drops (%) \nThis PI monitors ingress drops for both corrupted Ethernet frames and Ethernet frames dropped due to issues with the Ethernet payload. \nThis PI can be used as input for performance monitoring against a pre-defined Percentage KPI (percentage thresholds are set up for different severity levels). [%]
Tn_EthernetAllFaultsIn_Pct = 100 * (ifInDiscards + ifInErrors + ifInUnknownProtos + ifInUnknownTags) / (ifHCInUcastPkts + ifHCInBroadcastPkts + ifHCInMulticastPkts + ifInDiscards + ifInErrors + ifInUnknownProtos + ifInUnknownTags)

# 5.1.1.2 Ethernet Ingress Frame Errors (%) \nThis PI monitors ingress Ethernet frame errors and will indicate disturbances on the physical Ethernet level. The level of frame errors depends on the quality of the backhaul network.  [%]
Tn_EthernetErrorsIn_Pct = 100 * ifInErrors / (ifHCInUcastPkts + ifHCInBroadcastPkts + ifHCInMulticastPkts + ifInErrors + ifInUnknownProtos + ifInUnknownTags + ifInDiscards)

# 5.1.1.3 Ethernet Ingress Discard Frames (%) \nThis PI monitors valid ingress Ethernet frames being discarded due to the destination not being available. For example, this could be because the destination MAC-address does not resolve, or the IP TTL expires. \nThis PI indicates the amount of overhead traffic caused by not accepted frames, which is useful if there is an indication of link saturation.  Discarded frames decrease the throughput of the link without any physical reason. [%]
Tn_EthernetDiscardsIn_Pct = 100 * ( ifInDiscards + ifInUnknownProtos + ifInUnknownTags) / (ifHCInUcastPkts + ifHCInBroadcastPkts + ifHCInMulticastPkts + ifInErrors + ifInUnknownProtos + ifInUnknownTags + ifInDiscards)

# 5.1.1.4 Ethernet Egress TM Discard Frames (%) \nThis PI monitors the percentage of Ethernet frames discarded by the egress Traffic Manager. \nA high percentage of discarded frames can indicate that the link capacity toward the backhaul is too low. [%]
Tn_EthernetDiscardsOut_Pct = 100 * ifOutDiscards / (ifHCOutUcastPkts + ifHCOutBroadcastPkts + ifHCOutMulticastPkts + ifOutErrors + ifOutDiscards )

# Total duration in milliseconds where connection is lost due to Ethernet link failures, measured via the loss of signal detection. [ms]
Tn_EthernetLoSDuration_ms = ifTotalLossOfSignalDuration



#################
##    VLAN     ##
#################
# All of the counters for VlanPort MOs are based on "The Interfaces Group MIB" RFC 2863, which defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.
# For detailed descriptions of the counters, refer to the RFC 2863 memo.
# These counters are also used for other protocols & MOs, such as EthernetPort.

# 3.1.3.1 VLAN Ingress Rate (FPS) \nThis PI monitors the number of ingress frames per second (fps) at the MS RBS per VLAN ID. All parameters in the formula have corresponding entries in the SNMP MIB-2 IfXEntry tables (IF-MIB) if IfType equals to "135" (l2vlan). [fps]
Tn_VlanThroughputIn_Fps = ( ifHCInUcastPkts + ifHCInBroadcastPkts + ifHCInMulticastPkts ) / (900 * NR_ROP)

# 3.1.3.2 VLAN Ingress Rate (BPS) \nThis PI monitors the number of ingress bits per second (bps) at the MS RBS per VLAN ID. All parameters in the formula have corresponding entries in the SNMP MIB-2 IfXEntry tables (IF-MIB) if IfType equals to "135" (l2vlan). [kbps]
Tn_VlanThroughputIn_kbps = (ifHCInOctets * 8) / ( 900 * 1000 * NR_ROP)

# 3.1.3.2 VLAN Ingress Rate (BPS) \nThis PI monitors the number of ingress bits per second (bps) at the MS RBS per VLAN ID. All parameters in the formula have corresponding entries in the SNMP MIB-2 IfXEntry tables (IF-MIB) if IfType equals to "135" (l2vlan). [Mbps]
Tn_VlanThroughputIn_Mbps = (ifHCInOctets * 8) / ( 900 * 1000000 * NR_ROP)

# 3.1.3.3 VLAN Egress rate (FPS) \nThis PI monitors the number of egress frames per second (fps) leaving the MS RBS per VLAN ID. All parameters in the formula have corresponding entries in the SNMP MIB-2 IfXEntry tables (IF-MIB) if IfType equals to "135" (l2vlan). \nCounters are incremented before the egress traffic manager performs queuing and shaping. Therefore the PI may not match the actual transmitted frames if shaping or queue drops occur.  [fps]
Tn_VlanThroughputOut_Fps = ( ifHCOutUcastPkts + ifHCOutBroadcastPkts + ifHCOutMulticastPkts - ifOutDiscards ) / (900 * NR_ROP)

# 3.1.3.4 VLAN Egress rate (BPS) \nThis PI monitors the number of egress bits per second (bps) leaving the MS RBS per VLAN ID. \nCounters are incremented before the egress traffic manager perform queuing and shaping. Therefore the PI may not match the actual transmitted frames if shaping or queue drops occur. [kbps]
Tn_VlanThroughputOut_kbps = ( ifHCOutOctets * 8 ) / ( 900 * 1000 * NR_ROP)

# 3.1.3.4 VLAN Egress rate (BPS) \nThis PI monitors the number of egress bits per second (bps) leaving the MS RBS per VLAN ID. \nCounters are incremented before the egress traffic manager perform queuing and shaping. Therefore the PI may not match the actual transmitted frames if shaping or queue drops occur. [Mbps]
Tn_VlanThroughputOut_Mbps = ( ifHCOutOctets * 8 ) / ( 900 * 1000000 * NR_ROP)

# Ratio of inbound packets which were discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol & inbound packets which were discarded because of an unknown or unsupported protocol to all inbound packets. [%]
Tn_VlanDiscardsIn_Pct = 100 * ( ifInDiscards + ifInUnknownProtos ) / ( ifHCInUcastPkts + ifHCInBroadcastPkts + ifHCInMulticastPkts + ifInDiscards + ifInUnknownProtos )

# Ratio of outbound packets which were discarded even though no errors had been detected, for example due to lack of buffer space or traffic shaping to all outbound packets. [%]
Tn_VlanDiscardsOut_Pct = 100 * ifOutDiscards / ( ifHCOutUcastPkts + ifHCOutBroadcastPkts + ifHCOutMulticastPkts - ifOutDiscards )


#################
##     IP      ##
#################
#IP   Counters implemented by Ericsson are based on a Management Information Base for the Internet Protocol (IP), RFC 4293. 
#IP   Out of 46 counters proposed by RFC 4293, Ericsson implements 28 counters (and 5 additional ones).
#IP   The following Case diagram represents the general ordering of the packet counters.  
#IP   In order to avoid extra clutter, the prefixes "ipIfStats" have been removed from each of the counter names.
#IP   Note that HC stands for High Capacity 64-bit Counters.
#IP   
#IP   from interface                                  from upper layers
#IP     V                                               V
#IP     |                                               |
#IP     + InReceives                                    + OutRequests
#IP     |                                               |
#IP     |                                               |
#IP     +--> InHdrErrors                                +--> OutNoRoutes
#IP     |                                               |
#IP     |                                               |
#IP     +->-+ InMcastPkts                               |
#IP     |   V                                           |
#IP     +-<-+                                           |
#IP     |                                               |
#IP     +->-+ InBcastPkts                               |
#IP     |   V                                           |
#IP     +-<-+                                           |
#IP     |                                               |
#IP     |                                               |
#IP     +--> InTruncatedPkts                            |
#IP     |                                               |
#IP     |                                               |
#IP     +--> InAddrErrors                               |
#IP     |                                               |
#IP     |                                               |
#IP     +--> InDiscards                                 |
#IP     |                                               |
#IP     |                                               |
#IP     +--------+------->------+----->-----+----->-----+
#IP     |  InForwDatagrams (6)  |   OutForwDatagrams (6)|
#IP     |                       V                       +->-+ OutFragReqds
#IP     |                   InNoRoutes                  |   | (packets)
#IP     / (local packet                                 |   |
#IP     |  IF is that of the address                    |   +--> OutFragFails
#IP     |  and may not be the receiving IF)             |   |    (packets)
#IP     |                                               |   |
#IP     |                                               |   V OutFragOks
#IP     |                                               |   | (packets)
#IP     |                                               |   |
#IP     +->-+ ReasmReqds (fragments)                    +-<-+ OutFragCreates
#IP     |   |                                           |       (fragments)
#IP     |   |                                           |
#IP     |   +--> ReasmFails (fragments)                 +->-+ OutMcastPkts    
#IP     |   |                                           |   V
#IP     |   |                                           +-<-+
#IP     +-<-+ ReasmOKs (reassembled packets)            |
#IP     |                                               +->-+ OutBcastPkts    
#IP     |                                               |   V
#IP     +--> InUnknownProtos                            +-<-+
#IP     |                                               |
#IP     |                                               |
#IP     +--> InDiscards                                 +--> OutDiscards    
#IP     |                                               |
#IP     |                                               |
#IP     + InDelivers                                    + OutTransmits    
#IP     |                                               |
#IP     V                                               V
#IP   to upper layers                                 to interface


# 3.1.4.1 IP Ingress rate (PPS) \nThis PI monitors the number of ingress packets per second (pps). both valid and dropped packets, at the MS RBS per IP interface. All ingress IP packets received are counted, including those with errors. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [Pps]
Tn_IpThroughputIn_Pps = ipIfStatsHCInReceives / ( 900 * NR_ROP )

# 3.1.4.2 IP Ingress rate (BPS) \nThis PI monitors the number of ingress bits per second (bps) for both valid and dropped packets at the MS RBS per IP interface. All ingress IP packets received are counted, including those with errors. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [kbps]
Tn_IpThroughputIn_kbps = ( ipIfStatsHCInOctets * 8 ) / (900 * 1000 * NR_ROP )

# 3.1.4.2 IP Ingress rate (BPS) \nThis PI monitors the number of ingress bits per second (bps) for both valid and dropped packets at the MS RBS per IP interface. All ingress IP packets received are counted, including those with errors. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [Mbps]
Tn_IpThroughputIn_Mbps = ( ipIfStatsHCInOctets * 8 ) / (900 * 1000000 * NR_ROP )

# 3.1.4.3 IP Egress Rate (PPS) \nThis PI monitors the number of egress packets per second (pps) leaving the MS RBS per IP interface. Counters are incremented before the egress traffic manager performs queuing and shaping. Therefore the PI may not match transmitted frames if shaping or queue drops occur. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [Pps]
Tn_IpThroughputOut_Pps = ipIfStatsHCOutTransmits / ( 900 * NR_ROP )

# 3.1.4.4 IP Egress rate (BPS) \nThis PI monitors the number of egress bits per second (bps) leaving the MS RBS per IP interface. Counters are incremented before the egress traffic manager performs queuing and shaping. Therefore the PI may not match transmitted frames if shaping or queue drops occur. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [kbps]
Tn_IpThroughputOut_kbps = 8 * ipIfStatsHCOutOctets / (900 * 1000 * NR_ROP )

# 3.1.4.4 IP Egress rate (BPS) \nThis PI monitors the number of egress bits per second (bps) leaving the MS RBS per IP interface. Counters are incremented before the egress traffic manager performs queuing and shaping. Therefore the PI may not match transmitted frames if shaping or queue drops occur. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [Mbps]
Tn_IpThroughputOut_Mbps = 8 * ipIfStatsHCOutOctets / (900 * 1000000 * NR_ROP )

# 5.1.2.1 IP Ingress Drops (%) \nThis PI monitors ingress drops for both errors in IP packets header and IP packets discarded (e.g., for lack of buffer space) per interface for either IPv4 or IPv6. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [%]
Tn_IpAllFaultsIn_Pct = 100* (pIfStatsInDiscards + ipIfStatsInAddrErrors + ipIfStatsInHdrErrors + ipIfStatsInTruncatedPkts + ipIfStatsInUnknownProtos + ipIfStatsInNoRoutes + ipIfStatsInBlackHoles + ipIfStatsInSrcAddrErrors + ipIfStatsReasmFails ) / ipIfStatsHCInReceives

# 5.1.2.2 IP Ingress Errors (%) \nThis PI monitors ingress errors due to errors in IP packets header per interface for either IPv4 or IPv6. This PI can be used as input for performance monitoring against a pre-defined Percentage KPI (percentage thresholds are set up for different severity levels). \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [%]
Tn_IpErrorsIn_Pct = 100* ( ipIfStatsInSrcAddrErrors + ipIfStatsInAddrErrors + ipIfStatsInHdrErrors + ipIfStatsInTruncatedPkts ) / ipIfStatsHCInReceives

# 5.1.2.3 IP Ingress Discards (%) \nThis PI monitors ingress discards for where the IP packets couldn’t be further processed per interface for either IPv4 or IPv6. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [%]
Tn_IpDiscardsIn_Pct = 100 * ( ipIfStatsInDiscards + ipIfStatsInUnknownProtos + ipIfStatsInNoRoutes + ipIfStatsInBlackHoles ) / ipIfStatsHCInReceives
​
# IP Egress Discards (%) \nThis PI monitors Egress discards for where the IP packets couldn’t be further processed per interface for either IPv4 or IPv6. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [%]
Tn_IpDiscardsOut_Pct = 100 * ( ipIfStatsOutDiscards / ipIfStatsHCInReceives )

# Measures the percentage of received datagrams from lower layers successfully delivered to higher layers. \nCore metric for assessing how well the IP layer is processing incoming traffic. Low efficiency may indicate packet corruption, routing issues, or resource constraints. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [%]
Tn_IpEfficiencyIn_Pct = 100 * ( ipIfStatsHCInDelivers / ipIfStatsHCInReceives )

# Measures the percentage of received datagrams from higher layers successfully delivered to lower layers. \nTracks how many requested datagrams are successfully transmitted. Useful for tracking output performance. Significant deviations from 100% suggest issues with buffer overflows, congestion, or hardware limitations. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [%]
Tn_IpEfficiencyOut_Pct = 100 * ( ipIfStatsHCOutRequests / ipIfStatsHCOutTransmits )

# Indicates how often packets are fragmented due to MTU mismatches. \nHigh fragmentation rates can negatively impact performance and should prompt MTU optimization. \nFor additional information on the counters used for the KPI type: !grep '#IP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [%]
Tn_IpFragmentationRatioOut_Pct = 100 * ( ipIfStatsOutFragReqds / ipIfStatsHCOutRequests )

# A KPI measuring whether fragmented packets are successfully sent. Tracks how effectively fragmented packets are sent. Low success rates point to problems with IP fragmentation handling or resource shortages. [%]
Tn_IpFragmentationSuccessOut_Pct = 100 * ( ipIfStatsOutFragOKs / ipIfStatsOutFragReqds )

# Highlights packet loss due to failed fragmentation. Even small percentages can cause noticeable performance issues in applications relying on large packets. [%]
Tn_IpFragmentationFailureOut_Pct = 100 * ( ipIfStatsOutFragFails / ipIfStatsOutFragReqds )

# Monitors the efficiency of routing operations. Low values suggest misconfigurations or performance issues. It calculates the percentage of inbound IP packets that are being forwarded. \nHigh ratios could suggest a local processing function, such as on a host or server that does not forward traffic. \nLow ratios suggest the interface is primarily used for forwarding traffic between network segments, which is typical for routers or gateways such as the Baseband. [a:b]
Tn_IpInToForwardedPacketInRatio = ( ipIfStatsHCInReceives / ipIfStatsHCInForwDatagrams )
​
# Tracks the success rate of reassembling fragmented packets. Critical for large datagrams. \nA high KPI means most fragmented packets were successfully reassembled, indicating reliable handling of fragmentation. \nA lower KPI suggests issues with reassembly, such as packet loss, timeouts, or corrupted fragments. [%]
Tn_IpReassemblySuccess_Pct =  100 * ( ipIfStatsReasmOKs / ipIfStatsReasmReqds )

# Measures the proportion of fragmented packets that failed reassembly. \nA higher KPI indicates a high percentage of reassembly failures, suggesting potential problems with the network (High packet loss, Fragmentation-related issues, Poor link reliability). \nA lower KPI (close to 0%) means reassembly failures are rare, indicating good network performance for fragmented packets. [%]
Tn_IpReassemblyFailures_Pct =  100 * ( ipIfStatsReasmFails / ipIfStatsReasmReqds )

# Evaluates the efficiency of forwarding operations, helping identify problems with routing tables, congestion, or resource contention. \nIt measures the proportion of received IP packets that are successfully forwarded to another interface. \nA higher KPI indicates that most of the received packets are being forwarded, suggesting that the interface is primarily used for packet routing. \nA lower KPI suggests that a significant portion of packets are either destined for the local system or are being dropped. [a:b]
Tn_IpForwardingEfficiencyInRatio = ipIfStatsHCInForwDatagrams / ipIfStatsHCInReceives

# Measures inefficiencies caused by retransmissions, which can degrade throughput. \nIt calculates the IP Transmission Failure Rate, which measures the percentage of outgoing IP requests that were not successfully transmitted. \nA higher value indicates that a significant number of outgoing packets were not successfully transmitted, which could be due to issues like network congestion, errors, or interface problems. \nA lower value (close to 0) indicates that most packets are successfully transmitted, which generally reflects good network performance. [%]
Tn_IpOutRetransmissionOverheadOut_Pct = 100 * ( ipIfStatsHCOutRequests−ipIfStatsHCOutTransmits ) / ipIfStatsHCOutRequests

# This KPI calculates the Incoming-to-Outgoing Packet Ratio, which compares the total number of IP packets received from upper layers to the total number of IP packets successfully transmitted out of a (lower layer) interface. \nA higher percentage indicates that more packets are being received relative to the number of packets being transmitted, which is typical for a Baseband Traffic interface. [a:b]
Tn_IpInToOutPacketRatio = ipIfStatsHCInReceives / ipIfStatsHCOutTransmits


#################
##    SCTP     ##
#################
# Counters used for the SCTP KPIs are based on PM counters from Sctp MO & SctpAssociation MO.
# Majority of the counters for Sctp MO are standard and are part of the SCTP MIB (Management Information Base) as defined in RFC 3873 "Management Information Base for the Stream Control Transmission Protocol").
# Counters for SctpAssociation are loosely based on RFC 3873, however most are custom defined by Ericsson.

# SCTPAssociation  
# 3.1.5.1 SCTP IP-layer Ingress rate (BPS) \nThis PI provides the ingress IP-layer usage for a logical interface instance. It is the number of IP-layer bits received in SCTP IP packets from a remote SCTP peer during a granularity period. It includes SCTP packets received with errors. \nThe IP address and port number of the local SCTP endpoint with the IP address and port number of the remote SCTP peer identify the logical interface instance. \nThe ingress IP-layer average usage in Kbps for a specific logical interface is calculated using the below formula. [kbps]
Tn_SctpAssocThroughputIn_kbps = ( sctpAssocInOctets * 8 ) / (900 * 1000 * NR_ROP )

# 3.1.5.2 SCTP IP-layer Egress rate (BPS) \nThis PI provides the egress IP-layer usage for a logical interface instance. It is the number of IP-layer bits in SCTP IP packets supplied to the lower layer for transmission to a remote SCTP peer during a granularity period. It include SCTP packets that may be discarded by the lower layers e.g. packets discarded by the egress traffic shaping feature (egress traffic shaping). \nThe IP address and port number of the local SCTP endpoint with the IP address and port number of the remote SCTP peer identify the logical interface instance. \nThe egress IP-layer average usage in Kbps for a specific logical interface is calculated the below formula. [kbps]
Tn_SctpAssocThroughputOut_kbps = ( sctpAssocOutOctets * 8 ) / (900 * 1000 * NR_ROP )

# 3 4.1.5.1 SCTP Association Availability (%) \nThis PI provides the SCTP availability ratio for a logical interface instance. It is the percentage of time the SCTP association is available (with associationState in ESTABLISH state) during a reporting period. \nThe IP address and port number of the local SCTP endpoint with the IP address and port number of the remote SCTP peer identify the logical interface instance. \nThe SCTP availability ratio in % for a specific logical interface is calculated using the below formula. [%]
Tn_SctpAssocAvailability_Pct = 100 * ( 900 - sctpAssocTimeUnavail ) / (900 * NR_ROP)

# 5.1.4.1 SCTP Ingress Data Chunk Discard Ratio (%) \nThis PI provides the ingress SCTP data chunk discard ratio for a logical interface instance. It is the percentage of SCTP data chunks received from a remote SCTP peer for which no problems were encountered to prevent their continued processing but were discarded by the SCTP endpoint during a reporting period. \nThe IP address and port number of the local SCTP endpoint with the IP address and port number of the remote SCTP peer identify the logical interface instance. [%]
Tn_SctpAssocDataChunkDiscardsIn_Pct = 100 * ( sctpAssocInDiscardedDataChunks + sctpAssocInAbnormalDataChunks ) / ( sctpAssocInDiscardedDataChunks + sctpAssocInDataChunks + sctpAssocInAbnormalDataChunks )

# 5.1.4.2 SCTP Egress Data Chunk Discard Ratio \nThis PI provides the egress SCTP data chunk and user data discard ratio for a logical interface instance. It is the percentage of user data messages and the SCTP data chunks destined to a remote SCTP peer for which no problems were encountered to prevent their transmission but were discarded by the SCTP endpoint during a reporting period. \nThe IP address and port number of the local SCTP endpoint with the IP address and port number of the remote SCTP peer identify the logical interface instance. [%]
Tn_SctpAssocDataChunkDiscardsOut_Pct = 100 * ( sctpAssocOutDiscardedDataChunks + sctpAssocOutDiscardedUserMsgs ) / ( sctpAssocOutDiscardedDataChunks + sctpAssocOutDiscardedUserMsgs + sctpAssocOutDataChunks )

# 5.1.4.3 SCTP Ingress Control Chunk Discard Ratio. \nThis PI provides the ingress SCTP control chunk discard ratio for a logical interface instance. It is the percentage of SCTP control chunks received from a remote SCTP peer for which no problems were encountered to prevent their continued processing but were discarded by the SCTP endpoint during a reporting period. \nThe IP address and port number of the local SCTP endpoint with the IP address and port number of the remote SCTP peer identify the logical interface instance.  [%]
Tn_SctpAssocControlChunkDiscardIn_Pct = 100 * ( sctpAssocInDiscardedControlChunks + sctpAssocInAbnormalControlChunks ) / ( sctpAssocInDiscardedControlChunks + sctpAssocInControlChunks + sctpAssocInAbnormalControlChunks )

# 5.1.4.4 SCTP Data Chunk Retransmission Ratio (%). \nThis PI provides the egress SCTP data chunk retransmission ratio for a logical interface instance over a reporting interval. It is the percentage of SCTP data chunks retransmitted to a remote SCTP peer during a reporting period. \nThe IP address and port number of the local SCTP endpoint with the IP address and port number of the remote SCTP peer identify the logical interface instance. [%]
Tn_SctpAssocDataChunkRetransmission_Pct = 100 * ( sctpAssocRtxChunks ) / ( sctpAssocRtxChunks + sctpAssocOutDataChunks) 

# SCTP Failure Score:\nNumber of times that the association has :\n- a congested local transmission buffer.\n- become unavailable to the SCTP user due to ungraceful termination by the local or the remote side, using the chunk ABORT,\n- started the zero window supervision procedure,\n- become unavailable to the SCTP user due to graceful shutdown by the local or the remote side,\n- become unavailable to the SCTP user because all paths forming part of this association became inactive as Retransmission limit was reached,\n- become unavailable to the SCTP user because all paths forming part of this association became inactive as an ICMP message is received and is treated as if the retransmission limit was reached. [#]
Tn_SctpAssocFailureScore_Count = sctpAssocUnavailRtx + sctpAssocAborteds + sctpAssocShutdowns + sctpAssocCongestions + sctpAssocPeerZeroWindows

# Ratio of local transmission buffer for the association is congested to ROP time. [%]
Tn_SctpAssocCongestionLocal_Pct = 100 * sctpAssocTimeCongested / (900 * NR_ROP)

# This KPI shows the percentage of time the remote peer was unavailable to receive data due to a full buffer. [%]
Tn_SctpAssocCongestionRemote_Pct = 100 * sctpAssocTimePeerZeroWindow / (900 * NR_ROP)

# Average number of control chunks sent per outbound packet. \nHelps determine the efficiency of SCTP in bundling data and control information. Lower values indicate better efficiency. [a:b]
Tn_SctpAssocControlChunksPerPacketOut_Ratio = sctpAssocOutControlChunks / sctpAssocOutPacks

# Average number of control chunks sent out. \nHelps determine the efficiency of SCTP in bundling data and control information. Lower values indicate better efficiency. [a:b]
Tn_SctpAssocControlChunksToTotalOut_Ratio = sctpAssocOutControlChunks / (sctpAssocOutDataChunks + sctpAssocOutControlChunks)

# Average number of control chunks received. \nHelps determine the efficiency of SCTP in bundling data and control information. Lower values indicate better efficiency. [a:b]
Tn_SctpAssocControlChunksToTotalIn_Ratio = sctpAssocInControlChunks / (sctpAssocInDataChunks + sctpAssocInControlChunks)

# Measures the ratio of inbound packets to outbound packets. \nKPI helps identify traffic balance in the SCTP association. Values close to 1 indicate balanced traffic. Higher values indicate more inbound traffic, while lower values indicate more outbound traffic. [a:b]
Tn_SctpAssocPacketInToOut_Ratio = sctpAssocInPacks / sctpAssocOutPacks

# Average SCTP Association Delay [ms]
Tn_SctpAssocDelayAv_ms = sctpAssocDelayRTTAvg / NR_ROP

# Ratio of minimum RTT to maximum RTT. \nValues closer to 1 indicate stable latency with minimal fluctuations. [a:b]
Tn_SctpAssocDelayStability = sctpAssocDelayRTTMin / sctpAssocDelayRTTMax


# Sctp MO
# Number of times that SCTP associations have made a direct transition to the CLOSED state from:\n - the SHUTDOWN-SENT state, \n - the SHUTDOWN-ACK-SENT state,\n - from any state, using the chunk ABORT. [#]
Tn_SctpAssociationsCLOSED = sctpAborteds + sctpShutdowns

# Number of times that SCTP associations have made a direct transition to the ESTABLISHED state from:\n -  the CLOSED state,\n - COOKIE-ECHOED state. [#]
Tn_SctpAssociationsESTABLISHED = sctpPassiveEstabs + sctpActiveEstabs

# Average Outgoing Fragments per User Message.\n Estimates how many fragments are created for each sent fragmented user message. [fragments/message]
Tn_SctpFragmentsPerMessageOut = ( sctpOutUnorderChunks + sctpOutOrderChunks ) / sctpFragUsrMsgs

# Average Incoming Fragments per User Message.\n Estimates how many fragments are created for each received fragmented user message. [fragments/message]
Tn_SctpFragmentsPerMessageIn = ( sctpInUnorderChunks + sctpInOrderChunks ) / sctpReasmUsrMsgs

# Measures the average number of incoming chunks contained in each SCTP packet. \nThis KPI shows efficiency of SCTP packet utilization, High Chunks per Packet Indicate efficient use of network bandwidth, usually not present for telecom transport. [chunks]
Tn_SctpChunksPerPacketIn = ( sctpInUnorderChunks + sctpInOrderChunks + sctpInCtrlChunks) / sctpInSCTPPacks

# Measures the average number of outgoing chunks contained in each SCTP packet. \nThis KPI shows efficiency of SCTP packet utilization, High Chunks per Packet Indicate efficient use of network bandwidth, usually not present for telecom transport. [chunks]
Tn_SctpChunksPerPacketOut = ( sctpOutUnorderChunks + sctpOutOrderChunks + sctpOutCtrlChunks) / sctpOutSCTPPacks

# This KPI measures the percentage of received SCTP chunks that were discarded compared to the total number of received chunks (control + ordered data + unordered data). [%]
Tn_SctpChunksDiscardsIn_Pct = 100 * sctpInDiscardedChunks / ( sctpInCtrlChunks + sctpInUnorderChunks + sctpInOrderChunks)

# This KPI measures the percentage of transmitted SCTP chunks that were discarded compared to the total number of transmitted chunks (control + ordered data + unordered data). [%]
Tn_SctpChunksDiscardsOut_Pct = 100 * sctpOutDiscardedChunks / ( sctpOutCtrlChunks + sctpOutUnorderChunks + sctpOutOrderChunks)

# The number of received SCTP packets for which an SCTP association and/or endpoint could not be determined. NOTE: sctpInErrors + sctpInNoPorts = sctpOutOfBlues [Packets]
Tn_SctpPacketsUndeliverableIn_Packets = sctpInErrors + sctpInNoPorts




#################
##    TWAMP    ##
#################
# 5.1.5.1 TWAMP lostPktRt (%) \nThis PI monitors the drop ratio on the transport network for a specific TWAMP session. It gives the packet loss in percent (%) for a session on a round trip base. [%]
Tn_TwampPacketDrop_Pct = 100 * ( 1- (rxPkts + duplicPktFwd + duplicPktRev ) / txPkts )


#################
##    IP Sec   ##
#################
# 5.1.6.1 IPSec VPN Connection Ingress Packet Discard Ratio (%). \nThis PI monitors the ingress ESP packet discard ratio for an IPSec VPN ion over a 15-minute reporting interval. \nIt is the percentage of ESP packets (after outer IP reassembly) received on an IPsec VPN connection discarded by the eNB security protocol processor engine during a reporting period. \nATTN: use pmxen command to obtain the KPI. [Packets]
Tn_IPSecVPNConnPktDiscards_Pkts = 100 * ( espTunInReplayFail + espTunInIntegrityFail + espTunInInvalidSpi ) / ( espTunInReplayFail + espTunInIntegrityFail + espTunInInvalidSpi  + ipIfStatsHCInReceives )

# 5.1.6.2 IPSec VPN connection Egress Packet Discard Ratio (%) \nThis PI monitors the egress ESP packet discard ratio for an IPSec VPN connection over a 15-minute reporting interval. \nIt is the percentage of ESP packets (before outer IP fragmentation) destined to a remote IPsec peer discarded by the eNB security protocol processor engine during a reporting period. \nATTN: use pmxen command to obtain the KPI. [%]
Tn_IPsecVPNConnPktDiscardOut_Pct = 100 * espTunOutNoSA / ipIfStatsHCOutTransmits


#######################
##  Traffic Shaping  ##
#######################
# 5.1.3.1 Queue Drop Rate/Queue (%)\n This PI monitors the drop ratio caused by traffic shaping for a specific queue. \nIt helps to identify which queues are suffering from a high drop rate in congestion situations. [%]
Tn_QueueDropUpLink_Pct = 100 * ( queueHCDroppedOctets ) / ( queueHCInOctets + queueHCDroppedOctets )



#################
##     PTP     ##
#################
#PTP    Counters used for the PTP KPIs are not explicitly defined, but are typically derived from the IEEE 1588 Precision Time Protocol specifications.
#PTP   
#PTP    The chart below defines the IEEE 1588 synchronization mechanism and delay calculation:
#PTP   
#PTP    Master Clock                 Slave Clock
#PTP     T1 |                        |
#PTP        | \                      |
#PTP        |  \                     |
#PTP        |   \                    |
#PTP        |       Sync  Msg        |
#PTP        |                    \   |
#PTP        |                     \  |
#PTP        |                      V | T2
#PTP        |                        |
#PTP        | \                      |
#PTP        |  \                     |
#PTP        |   \                    |
#PTP        |    Sync FollowUp Msg   |
#PTP        |                     \  |
#PTP        |                      \ |
#PTP        |                       V|
#PTP        |                        |
#PTP        |                        |
#PTP        |                       /| T3
#PTP        |                      / |
#PTP        |                     /  |
#PTP        |    Delay Request Msg   |
#PTP        |   /                    |
#PTP        |  /                     |
#PTP     T4 | V                      |
#PTP        |                        |
#PTP        |\                       |
#PTP        | \                      |
#PTP        |  \                     |
#PTP        |   Delay Response Msg   |
#PTP        |                     \  |
#PTP        |                      \ |
#PTP        |                       V|
#PTP        |                        |
#PTP        |                        |
#PTP        V                        V    Time
#PTP            PTP Timestamps (T1 - T4)
#PTP    


# Synchronization Efficiency can be designed to provide an overview of the PTP system’s performance, incorporating both delay metrics and the accuracy of the offset from the master. \nA higher Synchronization Efficiency value suggests that the network has higher delays (both uplink and downlink) but is still able to maintain a reasonable offset from the master. This may indicate that the system is compensating for network delay but could benefit from optimization in the path. \nA lower value indicates better synchronization, where lower delays and smaller offsets from the master clock are achieved. This means the system is performing more efficiently with minimal delay and accurate synchronization.  \nThe ptpValidMeasurement counter to determines if reference is active during data collection period. If reference is inactive, KPI value will be N/A.
Tn_PtpSynchronizationEfficiency = ( ptpMeanPathDelayAvg + ptpDownLinkDelayAvg + ptpUpLinkDelayAvg) / ( ptpOffsetFromMasterAvg * ptpValidMeasurement )

# Measures the average time in ns offset between the master and slave clocks. A lower value indicates better synchronization. \nThe ptpValidMeasurement counter to determines if reference is active during data collection period. If reference is inactive, KPI value will be N/A. [ns]
Tn_PtpOffsetFromMasterAverage_ns = ptpOffsetFromMasterAvg / ptpValidMeasurement

# Measures the Stability in ns of the connection between the master and slave clocks. A lower value indicates better synchronization. \nThe ptpValidMeasurement counter to determines if reference is active during data collection period. If reference is inactive, KPI value will be N/A. [ns]
Tn_PtpOffsetFromMasterStability_ns = ptpOffsetFromMasterStDev / ptpValidMeasurement

# Average Mean Path Delay: Absolute value of average among measured mean path delay ((T2 - T1 + T4 - T3)/2) during granularity period. Indicates the minimum delay in communication paths. Helps identify the most efficient paths. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [ns]
Tn_PtpMeanPathDelayAverage_ns = ptpMeanPathDelayAvg

# Path Delay Variability: Standard deviation in measured mean path delay ((T2 - T1 + T4 - T3)/2) during granularity period. Measures the variability of the path delay, indicating the stability of network performance. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [ns]
Tn_ptpMeanPathDelayVariability_ns = ptpMeanPathDelayStDev

#Measures the ratio of lost packets in % in the PTP communication. Higher values may indicate network issues. [%]
Tn_PtpPacketLoss_Pct = 100 * ( ptpPacketsTx − ptpPacketsRx ) / ptpPacketsTx

# Frequency per second of received Delay Request messages used to measure the round-trip delay between the slave and master clocks. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [messages/s]
Tn_PtpMsgDelayRequestRx = ptpDelayReqRx / ( 900 * NR_ROP )

# Frequency per second of transmitted Delay Request messages used to measure the round-trip delay between the slave and master clocks. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [messages/s]
Tn_PtpMsgDelayRequestTx = ptpDelayReqTx / ( 900 * NR_ROP )

# Frequency per second of received Delay Response messages used to measure the round-trip delay between the slave and master clocks. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [messages/s]
Tn_PtpMsgDelayResponseRx = ptpDelayRspRx / ( 900 * NR_ROP )

# Frequency per second of transmitted Delay Response messages used to measure the round-trip delay between the slave and master clocks. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [messages/s]
Tn_PtpMsgDelayResponseTx = ptpDelayRspTx / ( 900 * NR_ROP )

# Frequency per second of received Sync messages received through this PTP port. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [messages/s]
Tn_PtpMsgSyncRx = ptpSyncRx / ( 900 * NR_ROP )
 
# Frequency per second of transmitted Sync messages transmitted through this PTP port. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [messages/s]
Tn_PtpMsgSyncTx = ptpSyncTx / ( 900 * NR_ROP )

# Frequency of Received Announce Message. The Announce message is sent periodically by the master clock to announce its identity and its time properties (such as its accuracy and quality). \nThis message contains important information about the clock's performance, such as its time source, accuracy, and current state. \nThe primary role of the Announce message is to help slave clocks or other devices in the network determine the best master to synchronize to. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [messages/s]
Tn_PtpMsgAnnounceRx = ptpAnnounceRx / ( 900 * NR_ROP )

# Frequency of Transmitted Announce Message. The Announce message is sent periodically by the master clock to announce its identity and its time properties (such as its accuracy and quality). \nThis message contains important information about the clock's performance, such as its time source, accuracy, and current state. \nThe primary role of the Announce message is to help slave clocks or other devices in the network determine the best master to synchronize to. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [messages/s]
Tn_PtpMsgAnnounceTx = ptpAnnounceTx / ( 900 * NR_ROP )

# Frequency of Received Follow_Up Message. The Follow_Up message in PTP is used in the two-step synchronization process. It is sent by the master clock in response to a Sync message. \nThe Follow_Up message contains the precise timestamp of when the Sync message was actually transmitted from the master clock, which is needed by the slave clock to accurately calculate the round-trip delay and the offset between the master and slave clocks. In One-step synchronization the Sync and Follow_Up messages are sent together in a single message. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [messages/s]
Tn_PtpMsgFollowUpRx = ptpFollowUpRx / ( 900 * NR_ROP )

# Frequency of Transmitted Follow_Up Message. The Follow_Up message in PTP is used in the two-step synchronization process. It is sent by the master clock in response to a Sync message. \nThe Follow_Up message contains the precise timestamp of when the Sync message was actually transmitted from the master clock, which is needed by the slave clock to accurately calculate the round-trip delay and the offset between the master and slave clocks. In One-step synchronization the Sync and Follow_Up messages are sent together in a single message. \nFor additional information on the counters used for the KPI type: !grep '#PTP' $moshelldir/commonjars/pm/FORMULA_TN_RCS.txt [messages/s]
Tn_PtpMsgFollowUpTx = ptpFollowUpTx / ( 900 * NR_ROP )

# Number of seconds during granularity period that PTP slave port has disqualifying defect, it cannot be selected as active synchronization reference. [s]
Tn_PtpReferenceDefectiveTime_s = ptpRefDefectTime
