This is a C++-based project that emulates the 5G packet analyzer by parsing the input file of raw packets and producing output human-readable-analysis in a file.
chmod +x app.sh
./app.sh build
./app run
Note: Sometimes, you may have to use sudo with chmod +x app.sh
You can use git bash to run on Linux, but in case you face any problems, you can do the following:
mkdir -p build
cd build
cmake .. -G "MinGW Makefiles"
make
Note: We implemented a logger and it is enabled by default, to disable it you can set the macro (DISABLE_LOGGING) in Include/Logger/Logger.h to 1
-
Ethernet Packet Frame:
-
Preamble: is a sequence of alternating 1s and 0s that helps the receiving device synchronize its clock with the transmitting device.
-
Destination Address: contains the MAC address of the intended recipient of the Ethernet frame packet.
-
Source Address: contains the MAC address of the device that is transmitting the Ethernet frame packet.
-
Types: specifies the protocol type of the data in the payload section. It indicates the upper-layer protocol to which the data should be passed.
-
Payload (Data): carries the actual data being transmitted. It can vary in size and content depending on the specific application or protocol being used. The payload can be a raw ethernet or e-CPRI frame depending on the Type field, it will be an e-CIPRI frame if the Type is
AEFE -
FCS (Frame Check Sequence): contains a checksum value calculated over the entire Ethernet frame, including all the preceding fields. It is used to detect errors in the transmission and ensure data integrity.
-
-
e-CPRI Packet Frame:
-
eCPRI Protocol Revision: identifies the version of the eCPRI protocol being used for the transmission. It helps ensure compatibility between different devices and software versions.
-
C: is a reserved bit that is used for future expansion of the protocol. It is currently set to 0.
-
eCPRI Message Type: specifies the type of message being transmitted in the eCPRI packet frame. There are several different message types defined in the eCPRI standard, each with its own specific format and purpose.
-
eCPRI Payload Size: specifies the size of the payload data being transmitted in the current eCPRI packet frame. This helps the receiving device know how much data to expect and how to process it.
-
RTC_ID: RTC stands for Real-Time Control, and the RTC_ID field is a unique identifier that is used to identify a specific instance of real-time control data. This identifier helps ensure that the correct data is being processed and acted upon by the receiving device.
-
SEQ_ID: is used to indicate the sequence number of the real-time control data being transmitted. This helps the receiving device keep track of the order in which the data was sent and detect any missing or out-of-order packets.
-
Real-Time Control Data: refers to any data that is used to control a system or process in real-time. Examples of real-time control data could include sensor readings, control signals, or other types of data that are used to monitor or adjust a system in real time. The specific format and content of the real-time control data can vary depending on the application or system being used.
-
- Simulator -> Ahmed Alaa
- PacketReader -> Fady Maged
- PacketParser -> Ahmed Alaa
- EthernetFrame -> Ahmed Alaa
- RowEthernetFrame -> Ahmed Alaa
- ECPRIEthernetFrame -> Ahmed Alaa
- ValidatorEthernetFrame -> Hazem Adel
- PrinterEthernetFrameVisitor (Ethernet or eCPRI) -> Fady Maged
- Logger, ConsoleLogger, FileLogger -> Ahmed Alaa
- UnitTestClass (...) -> [Future Work] Together
- Chain of Responsibilities -> Logger, ConsoleLogger, FileLogger
- Singleton -> ValidatorEthernetFrame
- Visitor -> PrinterEthernetFrameVisitor
-
Q: Why not use string which is easier? A: If we used strings, then every 1 byte in the packet will be stored as 2 bytes in the simulation's memory and every 1 byte is represented in 2 hex digits (and read as 2 characters). So, to save our memory, we chose to use unsigned char for each byte (2 hex digits or 2 characters from input_packets)
-
Q: Why did you save the original copy of the packet even after parsing it? Is not it a waste of memory? A: Yes, We tried to not take this decision but the e-CPRI packets in the input_packets file sample are not real packets and there is some error in them, like CRC is not equal to the CRC of the payload, in addition to the RTC data size is not equal to the payload size in the packet. (Ex: 1st packet's payload size = 23 bytes, but the data in the frame is 38 bytes) so we should compromise between 2 options:
- Ignore the payload size and count the bytes from the packet (which is not valid for simulation)
- Truncate some of the zero bytes at the end to reduce the 38 bytes to 23 bytes, but the output_packets will be different. So, we took the decision to keep a copy of the original 38 bytes to print it as it is and keep the parsed data to simulate the analysis correctly.
- Ahmed Alaa El-Sayed Arabi Zidan
- Fady Maged
- Hazem Adel