# Wireless Communications Study Notes Template
###### tags: `Wireless Communications`

## :notebook_with_decorative_cover: Personal Information
:::info
- Name: Sudhanshu Singh
- Research Direction: signal processing, system automation, Optimizing antenna design for wireless communication systems and 5G
- My background is in electronics and communication engineering, with a focus on antenna design. I am currently researching antenna design for image generation in self-driving cars, which involves optimizing wireless signal transmission for high-resolution data transfer essential for real-time imaging and sensor fusion. I want to take this Wireless Communication course to deepen my understanding of wireless networks, particularly 5G and beyond, and to enhance my skills in practical network analysis using tools like Wireshark. Specifically, Wireshark will help in my research by allowing me to capture and analyze wireless packets, debug protocol issues, measure latency and throughput in data transmissions, and identify interference or packet loss that could affect image quality and vehicle safety systems.
:::

PCAP Files link - https://drive.google.com/drive/folders/1DVzTmZ1HU3x82q91Kh8kaGum37yLPGKo?usp=sharing

Presentation video (google drive link) - https://drive.google.com/file/d/1D056LQ_7uzDNgL3WQTl3w_UBxG6DqL7e/view?usp=sharing

## :notebook_with_decorative_cover: Study Notes

# KS-Wireshark Installation Guide (Windows)

This guide explains step by step how I installed **KS-Wireshark** on my Windows Operating System, with screenshots captured during the process.

---

## Step 1 — Download the Installer
I first downloaded the KS-Wireshark installer from the official source. I downloaded it from the exe file provided to me by Professor

---

## Step 2 — Run the Installer
After the download finished, I opened the `.exe` file by double-clicking it. and then thos screenshoted image popped, asking me to run the 64bit KS Wireshark app. Click on Next.


---

## Step 3 — Accept the License Agreement
I accepted the license terms by selecting **I Agree** and then continued.


---

## Step 4 — Select Components
The installer asked which components I wanted to install (Wireshark, TShark, etc.).
I Selected all the components to install simultaneously so that i will be able to use maximum features of wireshark without seperately installing any driver


---

## Step 5 — Additional Task
The installer asks me "Which Additional Task to be done?". Eg: if i want a desktop icon after installation i could put it there, additionally i could also select that the App opens just after my installation. (It does not effect the app built in functions!)

---

## Step 6 — Choose Installation Location
I selected the default installation folder and clicked **Next**.


---

## Step 7 — Install Npcap or WinPcap
The installer prompted to install **Npcap** (required for packet capturing).
I chose to work with WinPcap as this might be new to me. it does not affect any thing as both Npcap and WinPcapdo the same work of packet capturing, its basically a driver.


---

## Step 8 — Install USBcap
The installer prompted to ask to install "USBcap". i dont want to capture my packets through USB port and hence i did not select that option. I actually have to capture data through the WiFi channel.


---

## Step 10 — Installation Progress
The setup showed the progress while files and drivers were being installed.


---

## Step 11 — Installation Complete
When the installation finished, I reached the **Finish** screen.
I selected the option to launch Wireshark and clicked **Finish**.


---

## Step 12 — Launch Wireshark
Wireshark opened successfully. I could now see available network interfaces and was ready to start capturing packets.

---

# ✅ Summary
- Downloaded and ran the KS-Wireshark installer.
- Accepted license and default installation settings.
- Installed **Npcap** for packet capturing.
- Successfully launched Wireshark on Windows.

Now my KS-Wireshark application is ready for use 🚀

---------------------------------------------------
# 🧪 Wireshark Lab – NTUST Homepage Analysis

## 🔹 1. What is the IP address and port of the NTUST homepage (https://www.ntust.edu.tw/home.php)?
**Answer:**
The NTUST homepage resolves to the following address based on the DNS and TLS packets captured:
| Type | Address / Port |
|------|----------------|
| **Server (Destination IP)**|`140.118.242.124` |
| **Port** | `443` (HTTPS) |

Explanation:
Port **443** indicates that the website uses **HTTPS** (secure HTTP).
This can be seen in the packets where the destination IP is **140.118.242.124** and the protocol used is **TCP / TLSv1.2**.


---

## 🔹 2. What is the IP address and port of your PC when initially accessing the page?
**Answer:**
| Type | Address / Port |
|------|----------------|
| **Client (Source IP)** | `192.168.50.10` |
| **Port** | `57386` |

Explanation:
The **source IP** represents the IP of your local computer on the LAN, and the **source port** (57386) is dynamically assigned by my system to start the HTTPS connection.


---

## 🔹 3. What is the process of the TCP three-way handshake?
**Answer:**
The TCP handshake between `192.168.50.10` (client) and `140.118.242.124` (server) follows these steps:

| Step | Flag | Description |
|------|------|--------------|
| **1. SYN** | `SYN` | Client → Server: Requests connection initiation |
| **2. SYN-ACK** | `SYN, ACK` | Server → Client: Acknowledges and agrees to connect |
| **3. ACK** | `ACK` | Client → Server: Confirms connection establishment |

✅ Once this three-step process completes, the encrypted **TLS handshake** begins.


---
# Part 2 — DNS Packet Analysis

## 🔹 4. What is the IP address and port of the DNS server?
**Answer:**
| Type | Address / Port |
|------|----------------|
| **DNS Server (Destination IP)** | `192.168.50.1` |
| **Port** | `53` |

Explanation:
All DNS requests in the capture are directed to **192.168.50.1**, the default gateway or router acting as the DNS forwarder.
Port **53** is standard for DNS communication.


---

## 🔹 5. What is the domain name in this query?
**Answer:**
The domain name queried is:
`www.ntust.edu.tw`

Explanation:
In the DNS query packets, the **"Standard query"** section clearly shows this domain name being resolved to its corresponding IP address (`140.118.242.124`).


---

## 🔹 6. Which protocol(s) does this DNS packet use?

**Answer:**
Based on the **Wireshark capture**, the DNS packet shown (querying `www.ntust.edu.tw`) uses the following protocols according to the **TCP/IP five-layer model**:

| Layer | Protocol | Description |
|--------|-----------|-------------|
| **Layer 5 – Application** | **DNS (Domain Name System)** | The packet contains a DNS query requesting the IP address for `www.ntust.edu.tw`. |
| **Layer 4 – Transport** | **UDP (User Datagram Protocol)** | DNS uses UDP by default on **port 53** for queries and responses. |
| **Layer 3 – Network** | **IPv4 (Internet Protocol Version 4)** | Provides logical addressing — here, **source IP:** `192.168.50.10`, **destination IP:** `192.168.50.1`. |
| **Layer 2 – Data Link** | **Ethernet II** | Defines the MAC addressing and frame type for data transmission within the local network. |
| **Layer 1 – Physical** | **(Frame / Physical Medium)** | Represented in Wireshark as *Frame*, showing capture metadata such as bytes on wire, captured length, and timestamp. |

**Explanation:**
In the captured packet:
- The DNS query for `www.ntust.edu.tw` is encapsulated inside **UDP**,
- which in turn is carried by **IPv4**,
- which is transmitted over **Ethernet II** at the data link layer,
- and the **Frame** entry in Wireshark provides physical layer capture information (e.g., number of bytes, interface).

**Protocol stack in Wireshark:**
> Frame → Ethernet II → IPv4 → UDP → DNS


---

## ✅ Summary Table

| Question | Answer Summary |
|-----------|----------------|
| NTUST Homepage IP / Port | 140.118.242.124 : 443 |
| Client IP / Port | 192.168.50.10 : 57386 |
| TCP Handshake | SYN → SYN-ACK → ACK |
| DNS Server IP / Port | 192.168.50.1 : 53 |
| Domain Queried | www.ntust.edu.tw |
| Protocol Stack | Frame → Ethernet II → IPv4 → UDP → DNS |

---

📘 **Observation:**
The client at **192.168.50.10** used the local DNS server **192.168.50.1** to resolve the NTUST homepage.
After receiving the IP address **140.118.242.124**, it initiated a **TCP three-way handshake** followed by a **TLSv1.2 handshake**, establishing a secure HTTPS connection on port **443**.

---

---------------
# 🧠 HTTP Page Access Analysis (Wireshark)

## 🔹 1. Which HTTP page did you access?
**Answer:**
`http://www.gzxyzn.com/Article/bjrk2/1644.html`

This can be seen from the packet line:

---

## 🔹 2. What is the IP address and port of the server hosting this page?
| Type | Address / Port |
|------|----------------|
| **Server (Destination IP)** | 61.183.8.129 |
| **Port** | 80 |
This could be seen at the TCP section in the screenshot provided below.
✅ The web server hosting the page is at **61.183.8.129:80**


---

## 🔹 3. What is the request method?
**Answer:** `GET`

Explanation:
The browser used an **HTTP GET request** to ask the server for the webpage data.


---

## 🔹 4. What is the response status code, and what does it mean?
**Answer:** The request version is `HTTP/1.1` and the response code is `200 OK`
We could view the Status code in Hypertext Transfer Protocol section below.

Explanation:
- **200 OK** → The server successfully processed your request.
- It means the requested page was found and returned correctly.


---

## ✅ Summary

| Question | Answer |
|-----------|---------|
| **HTTP Page Accessed** | http://www.gzxyzn.com/Article/bjrk2/1644.html |
| **Server IP Address** | 61.183.8.129 |
| **Server Port** | 80 |
| **Request Method** | GET |
| **Response Status Code** | 200 OK |
| **Meaning of Status Code** | Request successful – webpage delivered correctly |

---

📘 **Observation:**
All HTTP communication occurred over port **80** (standard for non-secure HTTP). The packet clearly shows a `GET` request from your machine to the web server, followed by a successful `200 OK` response.

----
----
----
----

# Homework 2 — 5G End-to-End Log Analysis
Wireless Communications — NTUST
Student: Sudhanshu Singh (M11402806)

---

# 1. UE Log Analysis
Log File: `2022_0411–UElog Reg ok PDU ok Ping complete.lsu`
Decoded using KS-Wireshark with NR-RRC and NAS-5GS enabled.

---

### 1.1 Cell PLMN (MCC + MNC)
**Concept:** The PLMN uniquely identifies the operator’s network. It is broadcast in SIB1 under `plmn-IdentityList`.

**From Log:**
- MCC = 001
- MNC = 01

**Final Answer:** **PLMN = 001-01**


---

### 1.2 Serving FR1 Band (freqBandIndicatorNR)
**Concept:** Indicates the NR frequency band used by the serving gNB.

**From Log:**
Found in `SIB1 → frequencyInfoDL → NR-MultiBandInfo`.
- freqBandIndicatorNR = 79

**Final Answer:** **FR1 Band = n79**


---

### **1.3 Is the gNB cell barred or not?**

To check whether the UE is allowed to camp on the serving cell, we examine the **MIB (Master Information Block)** in the UE log. The MIB contains the field `cellBarred`, which indicates if the cell is accessible.

**How it was checked:**
- Applied filter: `nr-rrc.cellBarred`
- Opened an RRC message where **Info = MIB**
- Expanded the structure:

  NR RRC
    → BCCH-BCH-Message
         → mib
             → cellBarred

**Log Result:**

cellBarred: notBarred

**Final Answer:**
The cell is **not barred**, meaning the UE is permitted to camp and proceed with registration.


---

### **1.4 What is the MSIN (Mobile Subscriber Identification Number)?**

The MSIN is part of the SUCI/SUPI (subscriber identity) transmitted by the UE during registration.
To locate it, we follow these steps:

**How it was found:**
1. Open NGAP → InitialUEMessage
2. Expand:
`5GS Non-Access Stratum (NAS) – Registration Request`
3. Expand the field:
`IE V-E: 5GS mobile identity (Length = 13)`
4. Inside this, the UE identity details are decoded: MCC, MNC, routing indicator, protection scheme, and **MSIN**.

**Result from the log:**

MSIN: 123456789

**Final Answer:**
The MSIN extracted from the UE's mobile identity is **123456789**.


---

### **1.5 What is the Registration Type and FOR?**

> ## **1.5 Registration Type and FOR**
> From the 5GS Registration Request:
> - **Registration Type:** Initial Registration (1)
> - **FOR:** Follow-On Request pending (1)
>
> *The UE is performing an initial registration and indicates that another NAS message will follow, so the network should keep the signaling connection active.*


---

## **1.6 What is the DNN?**
> In the *PDU Session Establishment Request*, the UE includes the Data Network Name (DNN) it wants to connect to:
> - **DNN:** `internet`
>
> This means the UE is requesting a PDU session towards the **public data network (internet APN)**.
> It is the standard DNN used for normal data services such as browsing, ping, and general IP connectivity.

#### **Screenshot:**

---

---

## **1.7 What is the SCC Mode in 5G?**
> In the *PDU Session Establishment Accept*, the network provides the Session and Service Continuity (SCC) mode:
> - **SCC Mode:** 1
>
> SCC Mode 1 means the UE’s PDU session remains anchored to the same UPF as the user moves across cells.
> This mode provides **seamless, uninterrupted data connectivity** and is the default continuity mode used for normal 5G mobile data sessions.


---

## **1.8 What is the PDU Address?**
> From the *PDU Session Establishment Accept*, the network assigns:
> - **PDU Address:** 172.16.0.1 (IPv4)
>
> This is the UE’s allocated IP address for the 5G PDU session, used for user-plane data such as ping and internet traffic.


---

## **1.9 What is the 5QI for this session?**
> **Answer:** The 5QI for this PDU session is **9**.
>
> **How it was found:**
> 1. Applied the display filter `nas_5gs`.
> 2. Opened **PDU Session Establishment Accept** (Deciphered NAS).
> 3. Scrolled down to **QoS Flow Descriptions (0x79)**.
> 4. Inside the QoS parameter section, the field
> **`5QI = 9`** was visible.
>
> **Meaning:** 5QI 9 corresponds to standard mobile broadband best-effort QoS used for normal internet data traffic.


---

## **1.10 What is the destination address of ICMP?**
> After applying the display filter `icmp`, the ICMP Echo Request packet clearly shows:
> - **Destination Address:** 22.22.22.22
>
> This means the UE was sending its ping test traffic toward the IP **22.22.22.22**.
> In this log, the ICMP messages (Ping Request/Reply) confirm that the UE successfully reached this destination through the assigned PDU session and the 5G user-plane path.


---
## **1.11 What is the period of MIB or SIB1?**
> In the UElog, the periodicity is visible inside the SIB1 broadcast message:
> - **ssb-PeriodicityServingCell: ms20**
>
> The MIB section in this log does not explicitly list a periodicity field, so the SIB1 value (ms20) is taken as the broadcast period used by the cell.


---

## **1.12 What is the Network Slicing (S-NSSAI) in the UE?**
> In the *rrcSetupComplete → s-NSSAI-List → item 0*, Wireshark shows:
> - `sst-SD: 01030609`
>
> According to 3GPP TS 24.501:
> - **SST = first 8 bits** → 0x01 → **1**
> - **SD = last 24 bits** → 0x03 06 09 → **030609**
>
> **Final S-NSSAI:**
> - **SST = 1**
> - **SD = 030609**


---

# 2. 5GC Core Log Analysis
Log File: `2022_0411–5GCsimlog Reg ok PDU ok Ping is less but ok.pcap`

---

## **2.1 What is the cell AllowedNSSAI in logs?**
>
> **Step 1 — Apply a display filter**
> I entered the following filter in the top Wireshark filter bar:
> ```
> Registration accept
> ```
> This filter shows only registration accept messages exchanged between UE and AMF, which includes the *Registration accept* message that carries Allowed NSSAI.
>
> **Step 2 — Locate the Registration accept message**
> In the packet list (top pane), I scrolled until I found a packet with:
> - **Protocol:** 5GS NAS
> - **Info:** *Registration accept*
>
> This is the message the AMF sends to the UE after successful registration, and it always contains the Allowed NSSAI IE.
>
> **Step 3 — Expand the NAS payload in the middle pane**
> After clicking the “Registration accept” packet, I expanded:
> - `5GS Mobility Management Message`
> - `Security Protected NAS Message`
> - `Plain 5GS NAS Message: Registration accept`
>
> Inside the Registration accept message, I scrolled down to the IE section.
>
> **Step 4 — Identify the Allowed NSSAI IE**
> Under the IE list, I located the block:
> ```
> IE TLV: Allowed NSSAI (0x2E)
> ```
> Expanding this IE shows the S-NSSAI provided by the network.
>
> **Step 5 — Extract SST and SD**
> Inside the Allowed NSSAI block, I zoomed into:
> ```
> S-NSSAI Value:
> SST: 1
> SD: 198153 (decimal) = 0x030609 (hex)
> ```
> This is the exact slice allowed by the AMF for this UE.
>
> **Final Answer Extracted:**
> - **SST = 1**
> - **SD = 198153** (0x030609)


---

## **2.2 What is the RRCEstablishmentCause?**
> In the 5GC pcap, under
> `NGAP → initiatingMessage → InitialUEMessage → protocolIEs → id-RRCestablishmentCause`,
> the value shown is:
>
> **RRCEstablishmentCause = mo-Signalling (3)**
>
> This means the UE establishes RRC connection for NAS signaling (registration, authentication, session setup), not for data-transfer.
> > ## **How I found the RRCEstablishmentCause in the 5GC log**
>
> **Step 1 — Apply NGAP filter**
> In the Wireshark display filter bar, I entered:
> ```
> ngap
> ```
> This shows only 5G core signalling between the gNB and AMF.
> The RRC establishment cause is forwarded inside the NGAP `InitialUEMessage`.
>
> **Step 2 — Locate the InitialUEMessage**
> In the packet list (top pane), I looked for a packet with:
> - **Protocol:** NGAP
> - **Info:** `initialUEMessage`
>
> This message is sent by the gNB to the AMF when the UE first tries to connect.
> It contains the UE identity and the **RRCEstablishmentCause** derived from the UE’s RRCConnectionRequest.
>
> **Step 3 — Expand the NGAP structure in the middle pane**
> After clicking the `InitialUEMessage` packet, I expanded:
> - `NGAP-PDU`
> - `initiatingMessage`
> - `procedureCode: id-InitialUEMessage`
> - `value`
> - `InitialUEMessage`
> - `protocolIEs`
>
> **Step 4 — Scroll to the RRCEstablishmentCause IE**
> Under the list of protocolIEs, I located the IE:
> ```
> id-RRCestablishmentCause
> ```
> Expanding this IE reveals:
> ```
> RRCEstablishmentCause: mo-Signalling (3)
> ```
>
> **Step 5 — Interpretation**
> - `mo-Signalling` means the UE is establishing RRC connection for NAS signaling
> (registration, authentication, PDU session setup).
>
> **Final Extracted Answer:**
> **RRCEstablishmentCause = mo-Signalling (3)**


---

## 2.3 What is the PDU Address?

To find the UE's PDU Session Address, I filtered the log for:
Then I opened the NAS message:

**5GS NAS → PDU Session Establishment Accept**

Inside the Information Elements, under:

- *IE TLV: PDU address (0x29)*
- *PDU Session Type: IPv4*

I found the assigned IP address:

👉 **PDU Address = 172.16.0.1**

This is the IPv4 address allocated to the UE for the PDU session by the 5G Core.
### Steps to find the PDU Address in Wireshark

1. Apply display filter:

2. Identify the NAS message:
**5GS NAS → PDU Session Establishment Accept**

3. Expand the following path in the middle pane:
- 5GS NAS
- PDU Session Establishment Accept
- IE TLV: PDU address (0x29)

4. Inside this IE:
- PDU Session Type shows **IPv4 (1)**
- The IPv4 value is displayed as:
**172.16.0.1**

This address is assigned by the 5G Core to the UE for data communication.


---

## 2.4 MSIN of UE/Subscriber (from 5GC log)

**Answer: MSIN = 1234567890**

How it was found (Step-by-step)

1. I applied the display filter:
`nas_5gs`
(This helps locate the *Registration Request* NAS message.)

2. I selected the packet with **Info = "Registration request"**.

3. In the middle pane, I expanded the following path:
- **5GS NAS**
- **Plain 5GS NAS Message**
- **Registration request**
- **IE IV-E: 5GS mobile identity**

4. Under **5GS mobile identity**, Wireshark decoded:
- SUPI format: IMSI
- MCC, MNC, and
- **MSIN: 1234567890**

5. The value was shown directly in KS Wireshark as:
**MSIN: 1234567890**


---

# 3. Self Practice

## 3.1 Periodic Registration Update Timer (T3512)
Found in `Registration Accept`.
**Answer:** ________

## 3.2 AMBR
Found in PDU session setup.
**Answer:** ________

## 3.3 Missing ICMP Replies
Count Echo Requests vs Replies.
**Answer:** ________

## 3.4 Voice Fallback to VoLTE
Check if IMS DNN or IMS NSSAI exists.
**Answer:** ________

## 3.5 QoSFlowSetupRequestList
Found in NAS + NGAP.
**Answer:** ________

## 3.6 supportedBandListNR
Found in UE Capability Information.
**Answer:** ________

## 3.7 TransportLayerAddress & GTP-TEID
Check GTP-U / PFCP messages.
**Answer:** ________

## 3.8 CP & UP Tunnel Information
Show TEID, QFI, TransportLayerAddress in one screenshot.
**Answer:** ________

---