## 1. Architecture

* Because according to the original connection method, you can only use calbe to ssh into the PV, but this line should be used for Google.com BBU. To ssh and connect to the base station at the same time, you need an extra line.
* How to set 172 to bind a network card when filling the system?
* Become one with 172 pairs of base stations, and the other is for ssh
* It should be set to 192.168.31 so that the wifi can ssh, but the ramp of pve itself is at 172, so I'm afraid it won't be usable

## 2. Network Setup
### 2-1. IP list
| Name | IP address | OS | Core | Memory | HDD |
| -------- | -------------- | ------------ | ---- | ------ | ---- |
| PVE | 172.18.200.102 | PVE 8.1.3 | 16 | 64GB | 1TB |
| 5GC-CP | 172.18.200.150 | ubuntu 20.04 | 8 | 32GB | 32GB |
| 5GC-UP | 172.18.200.151 | ubuntu 20.04 | 8 | 32GB | 32GB |
| UERANSIM | 172.18.200.152 | ubuntu 20.04 | 8 | 32GB | 32GB |

### 2-2. Network setup
#### A. PVE static IP settings
Use the PVE terminal to enter the config file, modify the address and gateway, and restart the network service.

nano /etc/network/interface

V

service networking restart

Unplug the Ethernet line from the router, plug it into the laptop, and set the static IP of the laptop to the same network segment 172 to enter the PVE dashboard again.

After entering, please pay attention to whether the picture below has been modified correctly.


And the IP in the host settings must also be changed.

#### B. VM static IP settings
SSH graph after DHCP allocation of initial three VMs

* When trying to set the static IP of the VM, the 5GC-CP setting failed, resulting in reassignment to 192.168.31.219


* Because there will be problems according to the instruction steps of try and apply according to the previous experimental notes, which are recorded below.
* When using commands to test (try) and apply (apply), the networkmanager service in the 50-cloud-init.yaml file will never be found.


* There is still no solution to find the name of the network service using the solution on the Internet, and the installation cannot be successful.


The last step is to shout down the VMs and then turn them on again. Make sure that the network card in the VM's hardware settings is changed from PVE to a static network card. If not, you need to add it yourself.

After booting, do not follow the steps in the previous test notes. Directly enter the file starting with 00 to set it (just like how to set a static IP in Ubuntu) and apply to successfully connect to the 172 network segment.

* CP
* UP
* UE

## 3. Config Info
### 3-1. BBU parameters
| Type | Value |
|:--------:| -------- |
| PLMN MCC | 001 |
| PLMN MNC | 06 |
| SST | 3 |
| SD | 000111 |
| DNN | internet |

### 3-2. UE parameters
| SIM | Value |
|:-----:| -------------------------------- |
| imsi | 001066010891152 |
| key | 1231786F6FE2F2A73309619385883B8C |
| opc | 4606CA1B2A5F512F51E61DF1CC220053 |
| ip | By PDU session |

* PVE can be connected directly through ssh. The user name is root, so there is no need to enter the computer room to set up.


* Entering /etc/networking/interfaces to modify the static IP of the second network card eno8403 will make the VM unable to connect.
* It seems that the gateway is occupied if it is repeatedly set, causing a conflict?
* Enter the interface and find that eno8403 is not enabled. If you customize the IP of the 172 network segment in the network, it will say that the 254 ramp has been used by vmbr0.


* After setting the static IP, shut down VM2 and try restarting PVE.
* After restarting the computer, the settings in the interface are still unchanged.
* It is found that after changing the network settings directly in the interface, you need to click Apply Settings
* Afterwards, enter /etc/networking/interfaces from the terminal and you will find that it has been modified.


* After resetting the network segment to 192.168.31 in the interface, it will still say that the default ramp is used.
* Setting it to 192 means that if you plug it into the router, you can use wifi to ssh, but this may not allow you to enter the VM.
* Do not add a gateway later. The default 103 second network card is connected to Google.com. Try adding this network card to the VM.


* Ping to see the base station

* Unable to ping, it seems that it still goes out from the default pve 102
* It is possible to ping both network cards and all VMs from the laptop, so try changing it to 102 pair of Google.com and 103 pair of laptops (this will not connect to the PVE backend, and it is not sure to ssh to the VM)

* Restart the three computers after setting up the network cards.
* After a while, I saw that eno8403, which was originally not enabled, became active again.


* Then you need to set up the static IP of the second network card in the VM for SSH. The first network card is currently used for SSH and is used to connect to the base station.
* CP (You can’t see the second one with ifconfig because there is no automatic IP allocation. Just use ifconfig -a to get it)


* UP

* The metric needs to be changed differently. If the via is changed to be the same as the first one, it will be broken (155 and 158 conflict)

* Later, the metric was changed to 1, and the via was changed to 253, so that both 155 and 158 can be entered (I thought only 155 was allowed, because the static gateway of the laptop is 254)

* After VM has set up two network cards, it can successfully ping from the second network card to Google.com


::: success
* New Router setup

:::

### The switch port of FHNET is not responsed
:::success
* Ask them for setting

:::

### Forgot to bring UE sim card
* Borrow the CPE & SIM card
* But need to find SIM card info.
* CPE dashboard doesnt have the info.

:::success
* Ask III.

:::

### Wireshark analysis results
* In the pcap file of 5GC-CP, we can see that CP receive the PDU request from BBU, then find UP to establish the PFCP tunnel (N4), when the tunnel is OK, CP send response to BBU.
* The response include the IP address of UP.
* When BBU receive the IP address of UP, we need to find whether BBU can find UP using its IP, so I serch the GTP tunnel (N3) and the IP address of BBU.
* And there are almost 10000 packets, but there is no BBU IP in source or destination IP.
* See the content of the first packet, we can find that **the source MAC is Supermicro (the server of BBU)**, and **below is from BBU IP to UP IP**, and **start IP is UE, end IP is google DNS.**

[TOC]
## Architecture

## Call Flow

## Step
1. We can Login `ssh [e-mail]` > Free 5GC > Config.


Here we can't modified in:

amfcfg.yaml
smfcfg.yaml
nssfcfg.yaml


We should not modify the files **amfcfg.yaml**, **smfcfg.yaml**, and **nssfcfg.yaml** in Free 5G because these files contain critical configuration settings for the AMF (Access and Mobility Management Function), SMF (Session Management Function), and NSSF (Network Slice Selection Function), respectively.

These functions play vital roles in the operation and management of the 5G core network. Modifying these configuration files without proper understanding or authorization can lead to network instability, service disruptions, or security vulnerabilities.

Furthermore, these configuration files are typically managed by network administrators or operators who have a deep understanding of the network architecture and requirements. Any changes made to these files should follow strict procedures and be thoroughly tested in a controlled environment to ensure the stability and security of the 5G network.

These codes are part of the configuration file for the SMF (Session Management Function) in a Free 5G network, the key components:

1. **dnnInfos**: This section contains information about the Data Network Name (DNN) and the associated DNS (Domain Name System) server addresses. It specifies the DNN "internet" and its corresponding DNS IPv4 and IPv6 addresses.

2. **plmnList**: This optional section lists the PLMN (Public Land Mobile Network) IDs that the SMF belongs to. It includes the Mobile Country Code (MCC) and Mobile Network Code (MNC) to identify the mobile network operator.

3. **locality**: This specifies the name of the location where a set of AMF (Access and Mobility Management Function), SMF, PCF (Policy Control Function), and UPFs (User Plane Functions) are located.

4. **pfcp**: This section defines the IP address configuration for the PFCP (Packet Forwarding Control Protocol) on the SMF. It includes the Node ID, Listen Address, and External Address for the N4 interface on the SMF.

5. **userplaneInformation**: This section provides information about the user plane nodes (AN or UPF) in the network. It includes details such as the node type, Node ID, and IP address of the N4 interface for each node. Additionally, it specifies the S-NSSAI (Single Network Slice Selection Assistance Information) and DNN information list for each UPF.

Running in `/free5gc_cp`
If we want to run, we can create `./cp.sh`


Running in `/free5gc_up`
If we want to run, we can create `sudo bin/upf`


Create a pcap file to restore and Execute tshark
If you want to interrupt tshark "Ctrl+C"

* Create file namely cap13.pcap by using **touch**
* Modify its file to read, write, and execute.
* Capture packages files to NIC "ens18" and save it to cap13.pcap

Free5gc_up

The provided data appears to be another packet capture (PCAP) log showing network communication between two IP addresses (172.18.200.32 and 172.18.200.154) using **NGAP/NAS-5GS protocol**. Let's analyze the functions represented by each line:

1. **InitialUEMessage, Registration request, Registration request**: This line indicates that the Initial UE (User Equipment) Message along with two Registration Requests were sent from 172.18.200.32 to 172.18.200.154.

2. **SACK (Selective Acknowledgment), DownlinkNASTransport, Registration reject (Implicitly deregistered)**: The second line shows a Selective Acknowledgment message along with a Downlink NAS Transport message, indicating a registration rejection (implicitly deregistered) response sent from 172.18.200.154 to 172.18.200.32.

3. **InitialUEMessage, Registration request, Registration request**: Similar to the first line, this line indicates the retransmission of the Initial UE Message along with two Registration Requests from 172.18.200.32 to 172.18.200.154.

4. **SACK, DownlinkNASTransport, Identity request**: A Selective Acknowledgment message along with a Downlink NAS Transport message indicating an Identity request is sent from 172.18.200.154 to 172.18.200.32.

5. **DownlinkNASTransport, Identity request**: A standalone Downlink NAS Transport message indicating another Identity request is sent from 172.18.200.154 to 172.18.200.32.

6. **DownlinkNASTransport, Identity request**: This line shows the repetition of the Identity request from 172.18.200.154 to 172.18.200.32.

7. **DownlinkNASTransport, Identity request**: Another repetition of the Identity request from 172.18.200.154 to 172.18.200.32.

8. **InitialUEMessage, Registration request, Registration request**: Similar to earlier instances, this line indicates the retransmission of the Initial UE Message along with two Registration Requests from 172.18.200.32 to 172.18.200.154.

9. **SACK (Selective Acknowledgment), DownlinkNASTransport, Registration reject (Implicitly deregistered)**: Similar to the second line, this line indicates another registration rejection (implicitly deregistered) response sent from 172.18.200.154 to 172.18.200.32.

10. **InitialUEMessage, Registration request, Registration request**: Another retransmission of the Initial UE Message along with two Registration Requests from 172.18.200.32 to 172.18.200.154.

This sequence of communications appears to involve registration attempts and identity verification between network entities, possibly related to device authentication or network registration in a 5G network environment.

Free5gc_cp

The provided data represents network communication between two IP addresses (172.18.200.32 and 172.18.200.154) using the NGAP (Next Generation Core Network (NGCN) Application Protocol) protocol. Let's break down the functions represented by each line:

1. **COOKIE_ECHO, NGSetupRequest**: This line indicates the initiation of the NGAP setup process with a COOKIE_ECHO message sent from 172.18.200.32 to 172.18.200.154, followed by an NGSetupRequest.

2. **NGSetupResponse**: The NGSetupResponse is sent in response to the NGSetupRequest, confirming the setup process from 172.18.200.154 to 172.18.200.32.

3. **InitialUEMessage, Registration request, Registration request**: This line indicates the Initial UE (User Equipment) Message along with two Registration Requests sent from 172.18.200.32 to 172.18.200.154.

4. **SACK, DownlinkNASTransport, Registration reject (Implicitly deregistered)**: A Selective Acknowledgment message along with a Downlink NAS Transport message indicates a registration rejection (implicitly deregistered) response sent from 172.18.200.154 to 172.18.200.32.

5. **DATA (TSN=1) (retransmission), UEContextReleaseCommand**: A retransmission of a DATA message along with a UEContextReleaseCommand is sent from 172.18.200.154 to 172.18.200.32.

6. **DownlinkNASTransport, Identity request**: An Identity request is sent from 172.18.200.154 to 172.18.200.32.

7. **NGReset**: A reset command is sent from 172.18.200.32 to 172.18.200.154.

8. **NGResetAcknowledge**: An acknowledgment for the NGReset command is sent from 172.18.200.154 to 172.18.200.32.

9. **DownlinkNASTransport, Identity request**: Another Identity request is sent from 172.18.200.154 to 172.18.200.32.

10. **ErrorIndication**: An error indication is sent from 172.18.200.32 to 172.18.200.154.

These lines represent various actions and responses involved in the establishment and management of network connections, registration attempts, and error handling within the NGAP protocol between the two IP addresses.

Configuration Router


Setting IP

Setting DHCP

Testing 5G trials are a crucial stage in the development and implementation of 5G networks. Here are the main conclusions that can be drawn from 5G testing trials:

1. **Performance Evaluation**: 5G testing trials allow experts and engineers to evaluate the performance of 5G networks in various scenarios and conditions. This includes measuring speed, latency, capacity, and network reliability.

2. **Technology Verification**: Testing trials enable the verification of new technologies used in 5G networks, such as Massive MIMO, beamforming, and network slicing. This helps ensure that these technologies can function effectively in real-world environments.

3. **Network Optimization**: Results from testing trials help network operators optimize their 5G infrastructure. By understanding weaknesses and challenges faced, operators can make necessary improvements and adjustments to enhance network performance.

4. **Validation of Use Cases**: Testing trials also aid in validating use cases for 5G applications across various industries, such as IoT, telemedicine, industrial automation, and autonomous vehicles. This ensures that 5G networks can support various types of services with the required reliability and performance.

5. **Commercialization Preparation**: 5G testing trials are also a crucial step in preparing for the commercialization of 5G networks. By gaining a better understanding of network performance and capabilities, operators can plan commercial launches more effectively.

In conclusion,5G testing trials are a critical process in the development and implementation of 5G networks, aiding in performance evaluation, technology verification, network optimization, validation of use cases, and preparation for commercialization. With the results from these trials, it is hoped that 5G networks can provide a superior experience for users and support broader digital transformation.

## Reference
* https://www.researchgate.net/publication/367890643_Evaluating_Dedicated_Slices_of_Different_Configurations_in_5G_Core