S. Kim et al.

: Design and Implementation of tiny-WiMAX Connection Manager (t-WCM) for Specific Purposed Devices

1825

Design and Implementation of tiny-WiMAX Connection Manager (t-WCM) for Specific Purposed Devices
Seokhoon Kim, Intae Ryoo, Member, IEEE, and Hangki Joh

Abstract WiMAX network services cannot generally be

provided for special purpose devices such as credit card systems and surveillance systems since they are designed to operate only with WCM which should be installed on personal computer/smart card (PC/SC) with Windows platform. In this paper, we propose a design and implementation technique called tiny-WiMAX Connection Manager (t-WCM) for non-PC/SC WCM to provide WiMAX services to special purpose devices. The t-WCM is composed mainly of three units; WiMAX module Control Unit (WCU), Data Surveillance Unit (DSU), and External device Program Unit (EPU). It also has TCP/IP protocol stack and RTOS kernel, and performs data transmission between external end users device and remote server system over WiMAX networks. For the performance evaluation of the proposed t-WCM, we have implemented the t-WCM and tested it under a commercial mobile WiMAX network environment. From the experimental results, the t-WCM is verified to show almost equal stability and delay performances with the legacy WCM and xDSL, and especially better than 1xEV-DO. As a result, it has a strong possibility to apply the t-WCM to many types of special purpose embedded systems, and consequently to provide various WiMAX network services to them.1
Index Terms WiMAX, Connection Manager, non-PC/SC

possible, which is the reason why WiMAX network services and legacy WCM could not deploy to the special purpose devices. Therefore, it is a widely accepted opinion until now that it is very hard to provide WiMAX network services to the special purpose devices. At the same time, on the other hand, the demands for applying the WCM to the special purpose devices and providing WiMAX network services to them have been steadily increasing. To solve these problems, we have proposed the tiny-WiMAX Connection Manager (t-WCM) for non-PC/SC WCM, which can be adopted by the special purpose devices with non-Windows platforms. The proposed non-PC/SC t-WCM has been designed and implemented to be used by small-scale systems and modems. In addition, the t-WCM is equipped with TCP/IP stack. So, we can provide various WiMAX network services to the special purpose devices just by connecting the modem with the t-WCM to them. We describe some basic PC/SC architecture in Sect. 2, and discuss the details about the design and implementation of the t-WCM in Sect.3. In Sect. 4, we verify the performance of the t-WCM by showing several experimental results, and bring this paper to a conclusion in Sect. 5. II. PC/SC ARCHITECTURE The PC/SC is a standard framework to use Integrated Circuit Card (ICC), also known as smart card, in a PC environment. The PC/SC and ICC interoperability specification have been developed to make it easy to introduce smart cards into normal PCs. The primary advantage of the PC/SC is that applications do not have to configure any details of the smart card reader in order to communicate with the smart card. That is, the applications can work together with any reader which complies with the PC/SC standard [1]. Figure 1 shows the PC/SC architecture which has the following major components. ICC Service Provider: This component is optional in the architecture. However, if used, it is very useful as it can easily provide standard interface to ICCs. ICC Resource Manager: This component is the core of the PC/SC architecture. Considering the truncation flow, it is located at a very important strategic position between applications and ICCs, and allows various applications to simultaneously access a given reader. It also helps applications identify and locate ICCs. These characteristics make it have simpler drivers and access resources easily. The ICC resource manager combines the common parts of the ICC readers drivers and applications into a set of reusable components. This reduces the overall software development cost. Interface Device (IFD, Smart Card Reader) Driver: This component translates the requests coming from the resource manager into a language that the reader can understand. It also chooses and sets an appropriate I/O channel for

I. INTRODUCTION Nowadays, most of the commercialized mobile WiMAX products are USB type modems that work only on PCs with Microsoft Windows operating system. This is because mobile WiMAX customers utilize only the normal Internet Web services. Similarly, the legacy WCM that users must use to connect to WiMAX networks can operate only with Microsoft Windows platform. Therefore, Universal Integrated Circuit Card (UICC) authentication method should also be applied to PC/SC with Windows platform. As recently proven in cellular networks and wireless LANs, the demand for providing wireless network services to special purpose devices (Credit Card Systems, Surveillance Systems, Healthcare Systems, etc.) is increasing. The situation is same as for the WiMAX network services. If these special purpose devices could use Windows platform based operating systems like Windows Mobile or Windows CE, they can use the normal WCM just by modifying the legacy WCM. But, it is a common sense that the special purpose devices would not adopt the heavy Microsoft Windows platform as their operating system. Generally, the special purpose devices should be configured with as light platform as
Seokhoon Kim, Intae Ryoo, and Hangki Joh are with Dept. of Computer Engineering, Kyunghee University, Korea (e-mail: kimsh@khu.ac.kr, itryoo@khu.ac.kr, and hkjoh@khu.ac.kr) Contributed Paper Manuscript received October 6, 2009
1

0098 3063/09/$20.00 2009 IEEE

1826

IEEE Transactions on Consumer Electronics, Vol. 55, No. 4, NOVEMBER 2009

communicating with the IFD, and manages more than one physical device. Potentially, the driver can be embedded with ICC resource manager [2].

The t-WCM has to communicate with outside networks line Internet. The t-WCM must meet the connection scenarios of IEEE 802.16e standards The t-WCM has to support UICC interworking functions. (If the special purpose devices do not have or support input interface, the t-WCM has to run this function via additional program or interface.) The t-WCM has to support extra security framework or block. The t-WCM must be able to support the save/search/transfer functions for the trouble history of WiMAX network services and support Over The Air (OTA) functionality. The t-WCM must be able to verify WiMAX network service status (network status, IP address, etc.) through the external display device. We have designed the t-WCM to meet the above-mentioned requirements and be able to support basic WCM functionalities as shown in Figure 2. The t-WCM is composed mainly of 3 functional units; WiMAX module Control Unit (WCU), Data Surveillance Unit (DSU), and External device Program Unit (EPU). It also has TCP/IP protocol stack and RTOS kernel, and performs data transmission between external end users device and remote server system over WiMAX networks. We describe the primary units of the tWCM in more detail in the following. WiMAX module Control Unit (WCU): This is a core unit which processes call connection/close, IP connection establishment, authentication, troubleshooting, and so on. The WCU normally sends and receives information with the WiMAX module, and transfers data to the EPU directly or via the DSU. The WCU is made up of 5 processes: Call Control Process: This process is related with WiMAX call controls. This process transfers data through USART/SPI/USB Rx/Tx Process1 which controls an interface that is physically connected to the WiMAX module. UICC Interworking Process: This process has the functions to control the UICC. The t-WCM does not consider the functions related with PIN configurations because most of the special purpose devices do not support external input device. Nevertheless, the t-WCM can use this process to configure PINs when there are additional input interface and specific program. Security Frame Process: This process is necessary when WiMAX network service providers want to apply their own security policies like MAC message authentications, data security algorithms, or security frameworks that are not defined in IEEE 802.16e standard. Status Information Process: This process has functions to display status information such as current WiMAX module status, signal strength (RSSI, CINR, etc.), network connection status (IP address, default gateway, subnet mask etc.) and so on.

Fig. 1. PC/SC Architecture

III.

TINY-WIMAX CONNECTION MANAGER

A. t-WCM Designs We have designed the t-WCM so that the special purpose devices with low communication speeds can use WiMAX network services with no performance degradation. Also, as stated in the previous section, some small scale embedded systems can utilize the t-WCM. The t-WCM has been designed to satisfy the following requirements: The t-WCM must be a kind of WiMAX Connection Manager that should be suitable for small scale embedded systems and have functionalities of legacy WCM as much as possible. The t-WCM must work well with non-Windows platform systems. The t-WCM has to be applicable to the systems that have hardware system or architecture with MCU (Micro Controller Unit). The proposed t-WCM must work with the MCU with 64Kb internal RAM or less The proposed t-WCM must work with the MCU with 256Kb flash memories or less The proposed t-WCM has to support additional interface for the special purpose devices

S. Kim et al.: Design and Implementation of tiny-WiMAX Connection Manager (t-WCM) for Specific Purposed Devices

1827

Troubleshooting Process: This process records some information about trouble histories and trouble status through DSU, and manages the OTA functions. HTTP can be used to run the OTA functions. But, FTP is the default protocol for OTA process. There need external RAMs and flash memories for the t-WCM to be able to support the OTA. Data Surveillance Unit (DSU): It has the functions related with system monitoring, alarm and so on. That is, if there are system malfunction errors (invalid application data information or transmission errors), they are sent to the troubleshooting process in the WCU. And then, troubleshooting process saves these errors into the flash memory. Note that normal data information is sent to an appropriate process in the WCU. External device Program Unit (EPU): This unit consists of External Device Function Process and Security Process, and processes data from external device. External Device Function Process: This process is responsible for processing data coming from an external device. Process operations are defined by the type of external device. That is, External Device Function Process is user defined process.

We do not consider the full TCP/IP protocol stack because it is too heavy to be applied to the embedded systems. RTOS Kernel: The RTOS Kernel can operate in a MCU. As mentioned, the proposed t-WCM is based on non-PC/SC method. So, the software parts of the PC/SC that are responsible for managing the PC/SC functions have to exist at some place which is not in the PC but in the non-PC/SC. The proposed tWCM, however, does not have software parts in its own area. Actually, these parts are located in the software module of WiMAX authentication. More specifically, WiMAX MAC firmware has the software parts of the PC/SC that are eventually integrated into one single unit. This is a very simple and reasonable way as the authentication module of the WiMAX MAC firmware has already have most of ICC control functions. Therefore, we can provide a device which works well without Microsoft Windows platforms. In addition, we can easily develop the WiMAX device and dramatically reduce the program size by using the proposed t-WCM design scheme. Figure 3 shows communication flows which are necessary for the successful operation of the t-WCM. The t-WCM uses following commands in this communication flows.

Fig. 2. t-WCM architecture and message flow

Security Process: This process is optional and includes SEED algorithms, RSA encrypt/decrypt functions, and so on [3-4]. When the process is enabled, it processes the encryption functions before data is send to the TCP/IP protocol stack. The decryption functions are done conversely. TCP/IP Protocol Stack: This stack includes some protocols that are necessary for the special purpose devices. For example, IP, UDP, ICMP, and FTP (HTTP is optional).

Fig. 3. Communication flows between t-WCM and WiMAX module

1828

IEEE Transactions on Consumer Electronics, Vol. 55, No. 4, NOVEMBER 2009

Boot Command: This is a start command to boot the WiMAX module. When the module receives this command, it will wake up from sleeping state. MAC Address Acquisition Command: This is responsible for getting the MAC address of WiMAX module. The MAC address is needed to initialize TCP/IP protocol stack. If the MAC address does not match the address in the TCP/IP protocol stack, the corresponding device with the t-WCM will not receive any reply from BS during DHCP process. Once the WiMAX module receives this command, it will transmit its own MAC address to the t-WCM. ICC Initialization Command: This is used to initialize ICC and IFD module related with PC/SC functions. When WiMAX module receives this command, it sends the ACK and initialization result to the t-WCM. ICC Application Setup Command: This is used to choose an ICC application. When WiMAX module receives this command, it sends the ACK, ICC Initialization Command. It also sets an ICC application, and the corresponding setting information is sent to the t-WCM. There are two security policies that can be used with the t-WCM. One is the security policy defined in IEEE 802.16e standards and the other is the defined by WiMAX service providers. But, in most of cases, the proprietary security policy is chosen because WiMAX service providers prefer their own security policies to easily reflect their rules, which is the reason why this command exists. RF Module Power-Up Command: This is a command which can wake up the RF part of WiMAX module. It is valid only when WiMAX module state is NULL. RF Module Power-Down Command: This is used to shut down the RF part of WiMAX module. It can also be used to re-initialize the WiMAX module. This command is valid only when WiMAX module state is Standby. Network Entry Command: This is a command for connecting to WiMAX networks. This command is valid only when WiMAX module state is Standby. In booting process, the t-WCM sends RF-Power-Up command to WiMAX module after the WiMAX module state is checked whether NULL or not. If the state is not NULL, the t-WCM performs WiMAX module initialization with RF Power-Down command. In case that WiMAX module receives RF Module Power-Up command, it sends a corresponding ACK to t-WCM and then transmits the changed state (Standby) to the t-WCM. In case that the t-WCM receives Standby state, it sends Network Entry command to WiMAX module so that it will try to connect to WiMAX networks.

Once WiMAX module receives Network Entry command, it changes its state from Network Entry to Ready, and continuously sends individual state information to the t-WCM. Ready state means that the WiMAX connection establishment is completed. And then, the t-WCM tries to obtain IP address through DHCP procedures. The way to establish IP connection is same as those used by other well-know communicating protocols. After all the previous steps are successfully completed, the t-WCM can transmit user data to a destination device. The t-WCM can close or disconnect the WiMAX connection by sending Network Disconnect command to the module. The module state must be Ready when t-WCM sends the command. Particularly, if BS transmits the action code which indicates disconnecting, close or disconnect process can be occurred. A message between the t-WCM and WiMAX module is verified by corresponding acknowledgement messages. This is why the t-WCM can utilize USART interface that provides low and unstable data transmissions. This process can be omitted, if the t-WCM uses another interface that can support high and stable data transmissions like SPI and USB. The WiMAX module state can be periodically sent to the tWCM. The intervals are generally ranging from 1 to 3 seconds, and can be changed by user. However, as this periodic state information may be a burden to the system performance, we can use the triggered updating scheme. B. t-WCM Designs We have been encountered with two major challenges in implementing the t-WCM. One is how to reduce the program size that is suitable for the embedded systems, and the other is how to guarantee the transmission performance that can satisfy various requirements of special purpose devices or embedded systems. In addition, the stability issues should also be resolved. First of all, we have carefully analyzed the legacy WCM functionalities to solve the first challenge, and we find solutions through this analysis. The solutions are as followings. PC/SC functions location: It can be moved to the WiMAX module. This is a very effective solution for reducing the t-WCM size. In addition, we have been able to amazingly upgrade the tWCM performance because t-WCM does not care about the PC/SC software parts which occupy the very complex portions in WCM architecture. In the proposed t-WCM, the concern is only about the results; whether the PC/SC process is successfully completed or not. This solution does not affect the WiMAX modules performance because the modules MAC firmware has already have most of PC/SC functionalities with enough processing power. Customizing, minimizing, and optimizing: The legacy WCM has many additional functions which are not closely related with WiMAX connectivity. This is because it operates on a device with enough processing power and storage to process these functions. The proposed t-WCM, however, has very limited functions. To reduce the size of the t-WCM to fulfill this condition,

S. Kim et al.: Design and Implementation of tiny-WiMAX Connection Manager (t-WCM) for Specific Purposed Devices

1829

we have chosen only the key components that are actually necessary to implement the t-WCM, as shown in Figure 2. Light-weight RTOS and TCP/IP stack Secondly, we have focused on the t-WCM performance. The goal is to achieve almost equal to or slightly less than that of the legacy WCM, and higher than the legacy cellular network technologies that are already used in the special purpose devices. These performance comparisons will be provided in detail in Sect. 4. Figure 4 show the Mobile WiMAX modem with the t-WCM. This is a mobile WiMAX modem because we have used the mobile WiMAX chipset which complies with IEEE 802.16e standards. Note that this implementation does not support full mobility. But, this is not the crucial problem here in this paper as we assume that most of the special purpose devices are located in fixed place. The major specifications that are used to develop this equipment are as following [5-12]. MCU: STM32 (64Kb Internal RAM and 256Kb Flash) with CortexTM- M3 core WiMAX Module: XRO3000 (Mobile WiMAX-IEEE 802.16e Wave2 RF Transceiver) and XRO7000 (Mobile WiMAX IEEE 802.16e Wave2 Modem SoC) RTOS: FreeRTOS v4.7.2 Compiler: IAR Embedded Workbench v4.2 TCP/IP Stack: NicheLite TCP/IP for ST ARMTM Language: C Language

implementation because the target system has USART interfaces by default. Table 1 shows the default configurations between these interfaces. Table 2 shows the overall comparisons of the proposed t-WCM with the legacy WCM. The executable file size of the t-WCM is small enough to be applied to embedded systems or special purpose devices. The size of flash image, t-WCM.bin file that we have developed, is actually about 143Kbytes, and the bootloader size is about 6.7Kbytes. The t-WCM supports the WiMAX network services without PC because it works well on non-PC/SC. Although the t-WCM does not support the full TCP/IP protocols, it has all the necessary protocols to connect the target system to the WiMAX networks. Our modem with the t-WCM has 4 LEDs that indicate modem status; power, radio sensitivity, transmission state, and trouble. The power and transmission LEDs are handled by the t-WCM, but the radio sensitivity and trouble LEDs are handled by Mobile WiMAX module because these 2 LEDs are tightly coupled with RF features of Mobile WiMAX module. Although the tWCM can support the OTA and PIN configuration functionality, they are optional functions. If necessary, they require additional hardware. If the OTA should be enabled, the modem must have additional flash memories and external RAMs because it has only 64Kb RAM and 256Kb flash. Similarly, the t-WCM does not normally use the PIN configuration function even though it can support this function. This is because the modem does not have input interface. Nevertheless, if PIN configuration function must be used in the target systems, an additional program can be used to set up the PINs through the second USART interface. This program is a kind of Windows application which can simply change the PINs. Although we have already developed this program, we do not mention about this program as it is not the key component focused in this paper.
TABLE I DEFAULT CONFIGURATIONS BETWEEN INTERFACES Paths t-WCM External Device Connection Speed 38,400 bps Remarks Different with External Device type Support from 9,600 to 115,200 Support High Speed USART

Fig. 4. Implemented Mobile WiMAX modem with t-WCM

The implemented mobile WiMAX modem has 3 USART interfaces. First USART interface is used to transmit data between the t-WCM and mobile WiMAX module, and second USART is used to display various information related with WiMAX networks and IP connectivity. Although the second interface has these functionalities, it does not directly connect to display device such as monitor. It shows only the information which has fixed formats. That is, user should utilize an application like HyperTerminal to see the information. The third USART interface is used to transmit data between the t-WCM and the special purpose device. In this paper, we have considered credit card authentication terminal (CAT) as a target system. As described in the previous section, the proposed t-WCM can support various interfaces such as SPI, USART, and USB. However, we have only considered USART interface in our

t-WCM Mobile WiMAX Module

115,200 bps

TABLE II COMPARISON OF THE PROPOSED T-WCM WITH LEGACY WCM

T-WCM

LEGACY WCM PC/SC Microsoft Windows IEEE 802.16e Desktop or Notebook PC > 20Mb Full TCP/IP Protocols in the PC Monitor

ICC mode Platform Standards Applicable Systems Executable File Size Supporting Protocols Display Type

Non-PC/SC Embedded RTOS (FreeRTOS v4.7.2) IEEE 802.16e Embedded Systems or Modems < 150Kb IP, TCP, UDP, FTP HTTP is optional LED

1830

IEEE Transactions on Consumer Electronics, Vol. 55, No. 4, NOVEMBER 2009

IV. Performance Evaluations We have applied the t-WCM to credit card authentication systems for performance evaluations. It is because the credit card authentication system is one representative example which needs WiMAX network services. In these systems, the traffics which contain the credit card information will be transmitted to the corresponding server. The server then process authentication information. This is completed within only one transaction. For this environment, we have implemented credit card authentication functions in the modem. That is, External Device Function Process and Security Process in EPU task, as shown in Figure 2, have these functionalities. For the performance evaluations, we compare the t-WCM modem with xDSL and 1xEV-DO modems which have already been used widely in South Korea. The Legacy WCM is used only for the stability test. Although it is not used in the credit card authentication systems, it provides Internet connection services for desktop or notebook PCs. Note that we do not consider throughput tests because the t-WCM modem has inevitable bottlenecks between CAT and WiMAX module, which is meaningless. As shown in Figure 5, we have used commercial network ecosystems for the performance evaluations. That is, our topologies which are used for the performance evaluations are real networks, and all the modems in this Figure are commercial products that are connected to CAT with 38,400bps through the USART interface. As for the public networks, we have used both 1xEV-DO and mobile WiMAX networks that are deployed by Korea Telecom. The USB dongle in the figure is equipped with the mobile WiMAX module with the t-WCM modem.

Figure 6 shows the ping response time to compare the stability of the t-WCM with that of the legacy WCM during 72 hours. The ping destination is www.yahoo.co.kr server. As shown in the figure, both the t-WCM and the legacy WCM have no problem in stability issue because they do not lose the connection within the test time. The average response times are about 234ms for the tWCM and about 227ms for the legacy WCM. From this test, we know that the t-WCM is working well with the target devices in the real networking environments. Figure 7 shows the delay comparison of the t-WCM with others measured at the CAT. We have done these tests concurrently, and each device has same functionality to authenticate the information. That is, the commercial xDSL and 1xEV-DO modems have the authentication functions which can encrypt and decrypt the information by SEED algorithms like the t-WCM modem. In the figure, the delay of the t-WCM is almost equal to that of the xDSL modem. The average delay of the t-WCM modem is actually 1.839 seconds per transaction and the average delay of the xDSL modem is 1.833 seconds per transaction. On the contrary, the delay of 1xEV-DO modem is 4.391 seconds, which means that the t-WCM greatly outperforms the 1xEV-DO. This is because the t-WCM has a very smart architecture and an efficient transmission mechanism than those of the 1xEV-DO. Although the architecture and the mechanism do not seem to be issues, they are very important in the real world because the actual data transmission sizes do not exceed at most 5Kb per one transaction. This does not result from the networking infrastructures of the mobile WiMAX and 1xEV-DO networks (these networks have enough bandwidths and capabilities), but from the architecture and mechanism that the proposed scheme has used. From these results, we can prove that our design goal for the t-WCM in Sect. 3 has been successfully accomplished.

Fig. 5. Network Ecosystems used in the tests

Figure 7. Delay comparison of the t-WCM with others

Fig. 6. Stability comparison of t-WCM with the legacy WCM

Most of wireless technologies can support idle and sleep modes to save power consumptions and radio resources. The Mobile WiMAX and 1xEV-DO also support these functions. Sometimes it can cause tremendous performance problems. If a device with these modes is aware of data transmission request, it must immediately wake up and then process the request. The way to support faster wake up from these modes is major criteria to determine the device performance. Figure 8 shows the delay comparison of the t-WCM modem with that of the 1xEV-DO

S. Kim et al.: Design and Implementation of tiny-WiMAX Connection Manager (t-WCM) for Specific Purposed Devices

1831

modem in the idle mode. Although the measurement methods are similar to that used in previous test except that it supports idle mode, we do not consider the xDSL modem in this test because it does not support the idle mode. In the figure, the average delays of the t-WCM and the 1xEV-DO are about 2.004 seconds per transaction and 4.562 seconds per transaction, respectively. By comparing these results with those in Figure 7, we know that the wake up times for the t-WCM and 1xEV-DO modem are about 0.165 seconds and 0.171 seconds, respectively. This small wake up time value means that the t-WCM modem runs a good mechanism in the idle mode. That is, the wake-up mechanism of the t-WCM is efficient enough to be applied to the commercial networks.

REFERENCES
[1] PC/SC Workgroup, Interoperability Specification for ICCs and Personal Computer Systems, Revision 2.01.01, Sept. 2005. [2] Gemmalto, Inc., PC/SC Architecture, <http://www.gemlto.com/techno/pcsc/other/aboutpscs.html> [3] ISO, Information technology Security techniques Encryption algorithms Part 3: Block ciphers, ISO/IEC 18033-3:2005, 2005. [4] H.J. Lee, S.J. Lee, J.H. Yoon, D.H.Cheon, J.I. Lee, KISA, The Seed Encryption Algorithm, IETF RFC4269, Dec., 2005. [5] IEEE, IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands, IEEE std. 802.16, 2006. [6] TTA, Specifications for 2.3GHz band Portable Internet Service - Physical & Medium Access Control Layer, TTAK.KO-06.0082/R2, 2008. [7] TTA, Wave 1 Protocol ICS for PHY/MAC Layer of 2.3GHz Portable Internet(WiBro), TTAE.KO-06.0204, [8] TTA, Wave 2 Protocol ICS for PHY/MAC Layer of 2.3GHz Portable Internet(WiBro), TTAE.KO-06.0205, 2009. [9] WiMAX Forum, WiMAX Forum Network Architecture Release 1.0 Version 4 Stage2: Architecture Tenets, Reference Model and Reference Points, WMF-T32-001-R010v04 ~WMF-T32-005-R010v04, Feb., 2009 [10] WiMAX Forum, WiMAX Forum Network Architecture Release 1.0 Version 4 Stage 3: Detailed Protocols and Procedures, WMF-T33-001R010v04, Feb., 2009. [11] Real Time Engineers Ltd., The FreeRTOS Project, <http://www.freertos.org> [12] InterNiche Technologies, Inc., NicheLite TCP/IP stack for STM32, <http://www.iniche.com>

Figure 8. Delay comparison of t-WCM with 1xEV-DO in the idle mode

BIOGRAPHIES

V. CONCLUSIONS AND REMARKS The proposed t-WCM has several advantages to be applied to any device. The t-WCM is based on non-PC/SC, has very simpler design concept than the legacy WCM, and can work well without Microsoft Windows platforms. The t-WCM can not only be directly used with various embedded systems without external RAMs but also be applied to WiMAX modems. The various target systems can easily take advantage of WiMAX networks through the systems with the t-WCM. In addition, we have proven that the modem with the t-WCM outperforms the 1xEV-DO modem and shows similar performances to those of the xDSL modem and the legacy WCM through the tests in the commercial networks. The proposed t-WCM, however, would not be used with the common systems that do not have other interfaces than USART, SPI, USB. In this paper, the design and implementation scheme for the proposed t-WCM has been applied only for the devices that have USART interface. Application for the other types of devices is for further study. Although we have considered external RAMs and flashes to support flexibility and scalability, the t-WCM architecture has limited flexibility and scalability because its target systems are embedded systems which certainly have many restricted conditions. Finally, we can expect a good effect and efficiency to use the proposed t-WCM design and implementation method to develop various WiMAX devices and to advance the WiMAX deployments in the world.

Seokhoon Kim received the B.E. and Doctor Degrees in computer engineering from Kyunghee University, Korea, in 2000 and 2004, respectively. He is currently a research professor of the School of Electronics and Information at Kyunghee University, Korea. From 2004 to 2006, he worked at IPOne, Inc. as a senior engineer. And then from 2006 to 2009, he worked at Neowave, Inc. as a senior engineer. His research interests include Mobile IPTV, 4G, Crosslayer, and Future Internet. Intae Ryoo received the B.E., M.E. and Doctor
Degrees in electronics engineering from Yonsei University, Seoul, Korea, in 1987, 1989 and 1994, respectively. And he received the Ph.D. degree from the University of Tokyo, Japan in 1997. He is currently a professor of the School of Electronics and Information at Kyung Hee University, Korea. From 1994 to 1997, he was a scholarship student supported by the Japanese Government (Monbusho). From 1997 to 1999, he worked at Samsung Electronics Co., LTD as a senior engineer. His research interests include multimedia communications networks, IPTV and future Internet. He is a member of IEEE, IEICE, Korean Society for Internet Information (KSII) and Korean Institute of Communication Sciences (KICS).

Hangki Joh received the B.E. and M.E. Degrees

in computer engineering from Kyunghee University, Korea, in 2004 and 2008, respectively. He is a Ph.D. candidate in Dept. of Computer Engineering of Kyunghee University. He worked at Samsung Electronics Co., LTD as an engineer from 2004 to 2005. His research interests include QoS/QoE, IPTV and Cross-layer technologies.