Abstract: In the context of the rapid development of mobile phone value-added services in recent years, this paper proposes an application solution for value-added service technology based on embedded systems, considering the current situation of the widespread application of embedded systems in people's daily lives and the characteristics of the current SP (Service Provider) value-added service system architecture. And through detailed explanation of the design and implementation of each functional module of the system, the technical characteristics and design ideas of the entire value-added service system are clarified. Keywords: Embedded system; Value-added service; Short message 1. Introduction In recent years, with the rapid development of mobile phone technology and the continuous increase of functions, people's use of mobile phones is no longer limited to traditional voice calls, but increasingly uses non-voice functions, such as SMS (Short Message Service), MMS, etc., which are mobile phone value-added services [1]. If mobile phone value-added services can be applied to embedded systems, enabling mobile phones to interact with embedded systems via short messages, then the development prospects of such value-added service technology will be very promising. This paper presents a complete solution for such value-added service system. In the development, the program part of the embedded system uses the Keil C development environment, while all other programs are written in Java and have been successfully ported to the Linux platform. In addition, the database used by the SP mentioned below is SQL Server 2000. The design and implementation of the entire value-added service system will be discussed below. 2. Overall architecture of the value-added service system The value-added service system architecture and interface provided by major mobile operators to their SPs are similar[2]. For example, the architecture of China Mobile is shown in Figure 1. The entire value-added service system based on the embedded system consists of the embedded system, the value-added service system gateway, and the SP and its embedded access module. The SP is responsible for providing users with a variety of value-added services. However, if it cannot apply to become an SP due to insufficient funds, it can embed an access module in the existing SP to achieve the same purpose of providing value-added services. This article introduces this solution. When the MS (Mobile Subscriber) wants to send a short message to the embedded system, the short message is first sent to the base station, and the base station then sends it to the SMSC (Short Message Service Center). The SMSC then forwards the short message to the ISMG (Internet Short Message Gateway) through the SMPP (Short Message Peer to Peer) protocol[3]. ISMG is the portal for communication between China Mobile and its SP. The underlying layer of communication between ISMG and SP is TCP/IP protocol, while the application layer is CMPP (China Mobile Peer to Peer) protocol. Figure 1 shows the overall architecture principle of the value-added service system based on the embedded system. Then, the SP receives all the necessary information about this short message from ISMG according to the CMPP protocol (such as the mobile phone number of the MS, the service code of the MS, etc.) and transmits the relevant data of the short message to the access module embedded in the SP. Then the access module sends it to the value-added service system gateway through TCP/IP. The gateway parses the information and re-encodes it, and then sends it to PSTN (Public Switched Telephone Network). Finally, the embedded system receives all the information of the short message from PSTN and displays it on its LCD. This completes the short message communication from MS to embedded system, and the short message communication process from embedded system to MS is similar [4]. The following will introduce each functional module of each part of the system one by one and describe in detail how they are implemented. 3. Embedded System Section 3.1 Characteristics and Development Background of Embedded Systems Many embedded systems have serial ports and LCDs, enabling them to communicate with the outside world and display information through programming. However, due to the limited memory capacity of embedded systems, careful attention must be paid to conserving memory during program development. The embedded system used in this study is a VoIP system developed in Taiwan, using the 8051 series chip. It has two serial ports, one of which connects to the built-in modem for external communication. Additionally, it has a 128*64 LCD for displaying received SMS messages and a keyboard for inputting SMS messages to be sent. The entire embedded system development is based on the underlying serial port, LCD, and keyboard APIs, all provided by this Taiwanese company. 3.2 Introduction to Modem AT Commands AT commands are a modem command language used by all modem manufacturers. By connecting the serial port and modem with a cable, allowing input to the modem via the serial port, modems can communicate with each other via the PSTN using AT commands. This is because modems have two operating modes: command mode and data transmission mode. 3.3 Modem Communication Module Table 1 Custom Frames of the Modem Communication Module The modem communication module is the main body of the embedded system, responsible for communicating with the outside world (other modems). Since the transmission between modems is a continuous byte stream, it is necessary to define some frames built on the data link layer to distinguish each data packet to be transmitted from the continuous byte stream. As shown in Table 1, DLE STX and DLE ETX are user-defined constants with hexadecimal values ​​of 10 02 and 10 03, representing the start and end of a frame, respectively. If a frame contains these two constants, a DLE can be inserted when sending the frame. For example, 10 02 becomes 10 10 02 after inserting a DLE. When receiving the frame, if a continuous 10 10 is encountered, it is checked whether it is immediately followed by 02. If so, the 10 in the middle is deleted. This ensures that the correct data is received while avoiding incorrect frame extraction from the byte stream. The type field has two possible values: DATA, meaning a data frame, indicating that the frame transmits data; and ACK, meaning an acknowledgment frame, indicating that the frame is an acknowledgment of the receipt of a certain data frame. The frame sequence number is a unique identifier for the frame, continuously incrementing during transmission and reusing after reaching its maximum value. Since the length of English text messages can be up to 160 bytes (Chinese is 140 bytes), the content field is specified as 160 bytes. For data frames, the content field stores the content of the text message; for acknowledgment frames, the content field stores the frame sequence number of the received data frame. When the modem communication module receives a text message from the MS, it simply sends an acknowledgment frame. When the modem communication module sends a text message to the MS, it sends a data frame to the destination modem and then waits for an acknowledgment frame. If no acknowledgment is received within a certain time, the modem communication module will retransmit the data frame. After a certain number of retransmissions, it will abandon sending the data frame. If new data frames need to be sent while waiting for an acknowledgment frame, a certain number of data frames will be allowed to be sent. Once this number is exceeded, no more frames will be sent until an acknowledgment frame for the previously sent frames is returned. 4. Value-Added Service System Gateway Section 4.1 Functional Overview Figure 2 Value-Added Service System Gateway The main function of the value-added service gateway is to forward data between the PSTN and the Internet (data is transmitted via TCP/IP). Therefore, two classes are defined: Frame and ShortMessage. Internally, the objects transmitted between the Modem communication module and the protocol conversion module are Frames, while the objects transmitted between the TCP/IP communication module and the protocol conversion module are ShortMessages. Frames and ShortMessages are converted to each other through the protocol conversion module. Therefore, the gateway's function is to parse a Frame containing SMS content received from the PSTN, re-encode it into a ShortMessage, and then send it to TCP/IP; or to parse a ShortMessage containing SMS content received from TCP/IP, re-encode it into a Frame, and then send it to the PSTN. The activities of all modules in the gateway are recorded by calling the interface provided by the log module. Since the implementation of the protocol conversion module is relatively simple, and the design ideas of the gateway's Modem communication module and the embedded system's Modem communication module are similar, the only difference is that the gateway's Modem communication module calls the Java serial port API provided by Sun, which hides many underlying implementation details and is easier to use in development. Therefore, only the TCP/IP communication module and the log module are described below. 4.2 TCP/IP Communication Module The data packet confirmation/retransmission mechanism in this module is similar to the strategy of the Modem communication module. In order to improve work efficiency, two queue buffers can be established in this module: a sending queue and a receiving queue, which are used to store ShortMessage class objects that have not yet been sent or have just been received. There are two strategies for sending: long connection and short connection [5]. Long connection means that after the first connection is established with the remote host, the connection is maintained, so that data can be sent at any time; short connection means that the connection is established only when data is sent, and the connection is immediately disconnected after the data is sent, until the next data arrives and the connection is re-established. The disadvantage of long connection is that when the network fails, the previously established connection will be destroyed, resulting in the inability to send data, and it also occupies network resources for a long time. The biggest drawback of short connections is that when sending a large amount of data, establishing connections becomes too frequent, resulting in significant overhead. However, using a new connection each time is more reliable than long connections. All TCP/IP communication modules in the value-added service system mentioned in this article use a short connection strategy for sending data. The receiving strategy involves creating a main thread that continuously listens for data on the port. If new data arrives, a new child thread is created to process it. After processing, the child thread automatically terminates, while the main thread continues listening. The specific implementation framework is as follows: while(true) // Main thread run method body { Socket sock = serverSocket.accept(); // Listening for data Thread childThread = new Thread(sock); childThread.start(); // Start the child thread to process this data } 4.3 Log Module Logs are crucial for any system. Through log files, we can view every small activity in the system, and often, logs can be used for debugging and error finding. There are generally three types of information that need to be output to the log: 1) Information about normal activity, such as a data packet received by the communication module, a protocol conversion, etc.; 2) Error information, such as failure to parse a received data packet due to a network failure or an incorrect data packet format; 3) Debugging information: information used by developers to locate errors during the system development phase. This type of information should no longer be output to the log after development is complete, but the relevant statements should still be retained in the program, because the system may be found to have problems in the future, requiring program improvements and further debugging. A class `LogManager` can be created to implement the logging module's functionality. This class needs to provide three static methods, corresponding to the three types of information that need to be output to the log: 1) `LogManager.log(String info)` for normal activity output; 2) `LogManager.error(String info)` for error output; 3) `LogManager.debug(String info)` for debugging output. When outputting to the log file, the three interfaces should include their respective markers and output times. The specific output effects are as follows: [LOG][2003-08-11 11:41:56] Output for normal activity; [ERROR][2003-08-11 11:41:56] Output for error messages; [DEBUG][2003-08-11 11:41:56] Output for debugging information. Furthermore, XML files can be used to manage the configuration of the log module and the entire value-added service system. For example, to control whether debugging information is output, simply add a data item to the XML configuration file and read the value of this data item at the beginning of the LogManager.debug(String info) method and perform a judgment. If debugging information is not needed, exit the method directly. 5. SP Access Module Section 5.1 Functional Overview Since applying to become a China Mobile SP requires a considerable amount of funding, embedding an access module into the existing SP's value-added service system to provide value-added services is an ideal and inexpensive solution for establishing a value-added service system when funds are limited. The process of short message sending and receiving is completed by the access module and the host SP as follows: 1) When the TCP/IP communication module receives a ShortMessage object, it forwards it to the database access module. The database access module then converts the object into a record and inserts it into the SQL Server database. The host SP then reads the record and interacts with the ISMG to send the short message to the MS; 2) When the ISMG sends a short message from the MS to the host SP, the host SP converts the short message into a record and inserts it into the database. The database access module then reads it out and converts it into a ShortMessage object, which is then sent to the TCP/IP communication module and sent to the value-added service system gateway. Figure 3 SP access module The existence of the SP access module allows us to ignore any interaction between the SP and the ISMG, making the complex CMPP protocol invisible to us. This greatly reduces the difficulty of development and turns the sending and receiving of short messages in this module into a simple process of accessing the database [6]. The design and implementation of the TCP/IP communication module, the log module and the value-added service system gateway in Figure 3 are similar, so they will not be described again. 5.2 Database Access Module The function of this module is to use JDBC to access the SQL Server 2000 database, thereby completing the sending and receiving of SMS messages. There are multiple JDBC drivers. Generally speaking, using the dedicated driver provided by the database manufacturer is more efficient. Here, the general sun.jdbc.odbc.JdbcOdbcDriver[7] is used. The main operation is to access two tables: the ReceiveSMS table which stores received SMS messages and the SendSMS table which stores SMS messages to be sent. These two tables include important fields such as source number, destination number, message content, and the time of receiving or sending. The ReceiveSMS table also has a field IsRead which indicates whether the record has been read. 0 indicates that it has not been read and 1 indicates that it has been read. The specific operation flow of this module is as follows: 1) When receiving a short message, read the records in the ReceiveSMS table where the IsRead field is 0, then set the IsRead field of all read records to 1, indicating that the record has been read, and extract the fields of the read records as the attribute values ​​of the newly constructed ShortMessage object, and finally pass it to the TCP/IP communication module; 2) When sending a short message, first receive a ShortMessage object from the TCP/IP communication module, and use the attribute values ​​of the ShortMessage object as the field values ​​of the newly constructed record, and finally insert the new record into the SendSMS table. 6. Summary This paper discusses the difficulties and key points in the design of each functional module, which is a practical and promising value-added service application. The author's innovation is that a solution for the application of value-added service technology based on embedded systems is proposed, applying mobile phone value-added services to embedded systems, enabling mobile phones to interact with embedded systems via short messages. The development prospects of such value-added service technology are very promising. In the development, the embedded system program uses the Keil C development environment and has been successfully ported to the Linux platform. References [1] Xu Aijun, Peng Xiuhua. Programming and Application of C51 Windows Environment for Microcontroller High-Level Language [M]. Beijing: Electronic Industry Press, 2001, 11-13. [2] Hu Dake, Li Peihong, Fang Luping. Embedded Development Expert - Embedded Development Guide Based on 8051 Microcontroller [M]. Beijing: Electronic Industry Press, 2003, 25-26. [3] Lai Qiwen. Application of 8051 Microcontroller Embedded System [M]. Beijing: Science Press, 2002, 55-56. [4] Xu Yingxiao. Java Syntax and Network Application Design [M]. Beijing: Tsinghua University Press, 2002, 30-32. [5] Donahue. American Computer "Handbook" Series - Java Database Programming Handbook [M]. Beijing: Electronic Industry Press, 2003, 88-89. [6] Timothy Budd. Object-Oriented Java Programming Thinking (Revised Edition) [M]. Beijing: Tsinghua University Press, 2002.10-11. [7] Ran Chunyu, Zhai Xiangmei, Gu Chuan, Research and Design of SMS Management Platform Oriented to Multi-ISMG Gateway Protocol [J]. Microcomputer Information, 2006 Vol.22 No.27:P.143-145