1. Introduction Embedded systems, characterized by their application-centric nature, computer technology foundation, and customizable software and hardware, have won a huge market share, far exceeding the number of applications of general-purpose computers. With the development of the Internet/Intranet, various household appliances, from air conditioners to microwave ovens, have created a demand for Internet connectivity. How to share information of embedded devices via the Internet, achieve remote access, control, and management of devices, and monitor devices at various nodes connected to the network in real time—this is the problem that needs to be solved for devices to access the Internet. TCP/IP is a standard network protocol. If the TCP/IP protocol can be embedded into the MCU of a device, a communication link can be established between the device and the Internet, thus solving the key technology for device-to-network interconnection. 2. Characteristics of the Simplified TCP/IP Protocol Stack Just as embedded systems are application-specific, analyzing the characteristics of the embedded TCP/IP protocol stack and simplifying the traditional TCP/IP protocol stack must also be tailored to the specific system environment and application background. Discussing the characteristics of the embedded TCP/IP protocol stack and simplifying the TCP/IP protocol stack without considering the specific system environment and application background is meaningless. The embedded TCP/IP protocol stack discussed here is designed for low-end 8-bit/16-bit embedded systems that support embedded Internet direct connection architectures. Embedded systems have limited processing power and relatively scarce storage resources, making the standard TCP/IP protocol stack unsuitable for embedded Internet environments. Porting the TCP/IP protocol stack from a regular PC to an MCU presents memory and memory management bottlenecks. To achieve the necessary network functions while conserving system resources, targeted modular reduction of the protocol stack is necessary. A subset of the TCP/IP protocol suite, called the Simplified TCP/IP protocol stack, was designed for the 8-bit/16-bit MCU architecture in home appliance systems. This includes all or part of the functions of protocols such as IP, UDP, ARP, and ICMP, with selective implementations to maintain the integrity of protocol functions and mechanisms as much as possible. The Simplified TCP/IP protocol stack is designed according to the layered network architecture concept, as shown in Figure 1. Each layer is designed as a relatively independent module, responsible for processing its own data, and transferring control to the upper or lower layer modules through function calls. Low-end embedded systems generally lack real-time multitasking operating system support, so the Simplified TCP/IP protocol stack directly interacts with the hardware. The program structure in an MCU typically combines sequential execution with hardware interrupts. Embedded processors have low clock frequencies and narrow address and data buses, so processing a single IP packet takes a significant amount of time. If interrupt handling is used, it will inevitably affect the execution of other interrupts and tasks. When there are real-time tasks such as real-time data acquisition, serial communication interrupts, and keyboard interrupts in the system, conflicts will occur. Therefore, interrupt handlers need to be rationally divided during the design, placing the processing of the Simplified TCP/IP protocol stack, which has no real-time requirements and is time-consuming, within the main program's sequential loop. A polling approach is used for the network interface control chip, meaning the Simplified TCP/IP protocol stack is processed between the execution intervals of other interrupt tasks, sacrificing response speed for system reliability, as shown in Figure 2. 3. TCP/IP Protocol Stack Reduction While ordinary operating systems can support the complete TCP/IP protocol suite, embedded systems often find it difficult or unnecessary to do so. The protocols implemented in embedded systems must be designed according to the characteristics and functions of each system. In the TCP/IP protocol suite, only the parts relevant to actual needs are implemented, while unused protocols are not supported. The Simplified TCP/IP protocol stack supports the following protocols: 3.1 Address Translation Protocol—ARP Protocol. ARP is a special protocol used by certain network interfaces (such as Ethernet and Token Ring). ARP's address resolution function provides dynamic address mapping between IP addresses and hardware addresses used by the data link layer. In general computer systems, ARP caches are typically designed as bidirectional data links, allowing for easy dynamic addition and removal of the entire cache. However, this non-linear linked list cache structure is time-consuming when performing table entry matching and lookups, making it unsuitable for embedded systems. Therefore, the ARP address cache uses a linear array structure. It is stored contiguously and linearly in memory, resulting in fast lookup speeds. Embedded applications do not have many nodes, meaning the ARP cache capacity does not need to be large; therefore, the ARP cache is designed to be of a fixed size. Passive embedded servers primarily receive service requests from clients and provide services to them; that is, the embedded server does not actively send data frames to any host. Since the server, which is always in a passive state, does not need to send ARP requests to any host, the device only needs to process ARP requests and return ARP replies. Given this situation, the ARP protocol chooses to implement the ARP reply part. 3.2 Internet Protocol—IP Protocol The IP protocol is the core protocol in the TCP/IP protocol suite, providing unreliable connectionless datagram delivery services. All TCP, UDP, and ICMP data are transmitted in IP datagram format. The IP protocol is very important, but its implementation is relatively complex. Based on the requirements of implementing the Simplified TCP/IP protocol stack, simplifying the IP protocol requires adhering to two principles: ① Processing received IP datagrams and submitting them to the upper-layer protocol; ② Encapsulating UDP packets and handing them over to the data link layer for framing. When a device receives a datagram addressed to itself, it first determines whether it is its own datagram. If they do not match, the datagram is discarded; otherwise, it performs IP checksum verification. If the datagram is correct, the IP header is removed, and the IP data is submitted to the upper layer for processing. Generally, data packets need to pass through different physical networks, so the IP layer must support data packet fragmentation and reassembly. However, IP fragmentation and reassembly incur significant overhead, and existing networks generally support Ethernet. Furthermore, in the 8/16-bit embedded system used in this application, the transmitted data consists mainly of small-volume status or control information. Therefore, datagrams will not exceed the protocol's 1500-byte limit. If a very small number of data packets are indeed large, they can be processed in the program and transmitted in batches. Therefore, the IP fragmentation and reassembly functions can be omitted. The routing function of IP packets is then handled by the default gateway. 3.3 Internet Control Message Protocol—ICMP Protocol The ICMP protocol is designed for control, testing, and management functions within IP networks. ICMP has many message types, determined by both the type and code fields. To determine device reachability, the Simplified TCP/IP protocol stack primarily implements echo request and response messages. This program sends an ICMP echo request message to the destination host and waits for an ICMP echo response. For passive devices, it is not necessary to actively send echo requests; it is sufficient to recognize echo requests from other clients and send echo responses. To enable users to know whether a device is reachable, it should be able to respond to Ping echo requests. 3.4 User Datagram Protocol—UDP Protocol In the transport layer of the Simplified TCP/IP protocol stack, UDP is chosen as the transport layer protocol. Theoretically, TCP's reliability comes at the cost of many complex measures and the resulting increased overhead. TCP provides connection-oriented, reliable service, while UDP is connectionless. Because UDP lacks a reliability guarantee mechanism, it can perform data communication at full speed (i.e., fully utilizing the speed of physical communication equipment); and because UDP does not require point-to-point access, it can implement "one-to-many" and "many-to-many" broadcasting and multicasting of information. The unreliable transmission defect of UDP can be compensated for by adding code to the application layer to improve UDP reliability. For example, adding sequence markers to data allows for the detection and correction of data loss and out-of-order delivery at the application layer; acknowledgment mechanisms are used to ensure that data arrives safely at the receiver, etc. Due to the specific requirements of embedded systems, such as limited CPU speed, confined code length, and critical transmission rate, fast and simple bidirectional data transmission with embedded devices is generally paramount when interfacing with them. Therefore, reducing round-trip communication with embedded devices and making the network a more efficient communication medium is essential for embedded network protocol design. UDP has low overhead, a much higher transmission rate than TCP, and stronger real-time performance. Therefore, using UDP as the transport layer protocol in embedded TCP/IP protocols is a wise choice. Embedded systems may also have situations requiring high data transmission reliability. Since UDP lacks timing mechanisms, flow control or congestion management mechanisms, acknowledgments, and accelerated transmission of urgent data, corresponding measures are added to the application layer protocol, such as adding sequence markers to datagrams, timed waiting, and retransmission mechanisms, to compensate for its shortcomings. From an application perspective, the Simplified TCP/IP protocol stack is mainly used for home appliances connecting to the internet. For centralized monitoring of temperature, smoke, and humidity sensors once per second, the transmission is frequent, the packets are small, and only the front-end device needs to broadcast real-time status data to the network; therefore, UDP is a more suitable choice. 4 Simplified TCP/IP protocol stack processing flow The process of receiving data packets in the Simplified TCP/IP protocol stack is the process of parsing data packets. First, when a data frame arrives, the network interface control program reads it into the buffer and checks the protocol type field. For example, if the value is 0x0800, it means that the data field contains an IP packet; if the value is 0x0806, it means that the data field contains an ARP packet [6]. This determines which protocol module to use to process the packet. Data packets with the Ethernet frame header removed will be allocated to the IP cache or ARP cache. Then, the IP protocol processing module or ARP protocol processing module continues to parse it. ARP updates the ARP address mapping table or sends an ARP reply depending on the packet type. After parsing the data packet, the IP protocol processing module hands the data over to the UDP protocol processing module or ICMP protocol processing module. The ICMP protocol module will send back an ICMP echo reply packet. The process of sending data packets in the Simplified TCP/IP protocol stack is the process of encapsulating data packets. After the data is processed by a certain layer of protocol, a header of a certain format will be added to the header of the data packet. During the data packet processing by the IP protocol module, it obtains the physical address of the target host by calling the ARP protocol. The processing flow of the Simplified TCP/IP protocol stack is shown in Figure 3. Figure 3: Simplified TCP/IP Protocol Stack Processing Flowchart 5. Summary and Outlook To verify the feasibility of the scheme, the experiment used simple image transmission as the research object to test the operating effect of the Simplified TCP/IP protocol stack. The test results show that the probability of data packet loss is relatively high in high-volume image transmission systems. Of course, the performance would be better in application systems with relatively low data traffic, containing only a small amount of data and simple control commands or feedback information. Currently, the Simplified TCP/IP protocol stack technology still has some imperfections. For example, reducing the data packet loss rate in networks with large data volumes and more effectively controlling congestion are areas for future efforts. Furthermore, further code optimization is needed to improve the performance of the Simplified TCP/IP protocol stack.