WiMAX Multicast/Broadcast Services Support in Home ... - IEEE Xplore

S. Jeon and Y. Kim: WiMAX Multicast/Broadcast Services Support in Home Environments

1333

WiMAX Multicast/Broadcast Services Support in Home Environments Seil Jeon and Younghan Kim, Member, IEEE Abstract — Multicast/broadcast service (MCBCS) is one of the most advanced services of all wireless network standards. Recently, the WiMAX forum introduced MCBCS with three different types of internal data paths that differentiate the ways in which MCBCS data are packaged and delivered. In order to extend WiMAX access to the indoor users in home environment, femtocell technology has been considered. However, an application and evaluation of MCBCS structures over the WiMAX femtocell system have not been studied yet. In this paper, we therefore classify the applicable MCBCS network model for home users in femtocell systems and evaluate the performance of each model in terms of transmission overhead and buffer size required in data packaging. From the results, we note that the separated femto model using type-3 and type-4 data paths has more transmission overhead and requires more buffers than type-1, but these are reduced when the error rate decreases between the femto gateway (Fe-GW) and the WiMAX femto access point (WFAP). Moreover, we confirm that there are no differences in performance among types of model in the combined femto model.1. Index Terms — multicast/broadcast services, MCBCS, MBS, WiMAX.

configures all radio resources and parameters and delivers MAC-level information and parameters through application layer signaling. These types have different functions and mechanisms for providing MBS synchronization rules, processing, and delivery of MCBCS data [6]. Thus, when we design MCBCS services over a WiMAX femtocell system, we need to consider several combinations of physical location of WiMAX femto ASN-GW (Fe-GW), and the location of MBS sync and distribution function according to the MCBCS structure. In this paper, we classify the applicable MCBCS network model for home users within a femtocell system and evaluate the performance of each model in terms of data delivery overhead and buffer size required for data packaging. The rest of this paper is organized as follows. In section II, we describe the structures of WiMAX femtocell systems and the WiMAX MCBCS. In section III we present applicable models for providing MCBCS in a home femtocell environment, and, in section IV, analyze the performance of each model and show results using real network parameters. Finally, conclusions are offered in section V. II. DATA PATH MODELS FOR WIMAX MCBCS SUPPORT AND WIMAX FEMTOCELL SYSTEM ARCHITECTURE

I. INTRODUCTION Recently, a growing demand for wireless multimedia applications has motivated research into multicast/broadcast services (MCBCS or MBS) over mobile WiMAX networks to provide wide-area coverage and higher performance of handover; however, it is very difficult for indoor users to serve WiMAX MCBCS in a home environment because of significant penetration by outdoor signals. For higher service availability of WiMAX in a indoor place, the WiMAX forum has commenced the development of femtocell standards [1][2]. With coverage extension, femtocell technology enables the convergence of landline and mobile services because the same handheld device can be used to access a broadband wireless connection indoors and outdoors [3]. But until now, the use of MCBCS over a femtocell network has not been studied. The structure of WiMAX MCBCS has three types of data paths: type-1 and type-3, which are based on dynamic service flow (DSx) [4] that manages service flow for each MS through DSx messages between MS and BS, and type-4 [5], which pre1 Seil Jeon and Younghan Kim are with the School of Electronic Engineering, Soongsil University, Sangdo-Dong, Dongjak-Gu, Seoul 156-743, Republic of Korea (e-mail: [email protected], [email protected])

Contributed Paper Manuscript received 07/15/10 Current version published 09/23/10 Electronic version published 09/30/10.

Fig. 1 Femtocell System Architecture in WiMAX Networks

Fig. 1 shows the architecture of a femtocell system, which consists of the femto network service provider’s (NSP) part and the femto network access provider’s (NAP) part. The femto-NSP manages user subscriptions and provides IP connectivity for WiMAX users, and the femto-NAP, the access service network, is composed of the Fe-GW and the WFAP. The Fe-GW has the same role as an ASN-GW, and they are connected with an R4 interface for interoperability with a macro network.

0098 3063/10/$20.00 © 2010 IEEE

1334

IEEE Transactions on Consumer Electronics, Vol. 56, No. 3, August 2010

Fig. 2 MCBCS Architecture

An R3 interface is used to transfer user data between the femto-ASN and the macro-CSN. The functions of the Fe-GW and the WFAP can be physically separated into two entities or integrated into a single entity. The WFAP is connected to a self-organization network (SON) server, which is the management entity, with an Rm interface. The SON server scans and analyzes radio information from WFAPs, then it transmits the fine-tuned radio parameters to the WFAPs to avoid interference with macrocell or other femtocell BSs. This process is periodically managed by an SON server. A. Data Path Model for WiMAX MCBCS Support Fig. 2 shows the three types of network reference architectures for MCBCS. The MCBCS content server, located at CSN, which stores MCBCS content, manages IP multicast groups and provides application-level security. The MBS proxy performs the role of session manager between ASN and CSN and manages the distribution DPF. Additionally, it has the role of a policy enforcement point, assigning wireless parameters such as MCID and MBS service flow. The architecture is different depending on the location of synchronization executers and resource and parameter configuration methods. In type-1 and type-3 architectures, service flow authorization (SFA) manages MSs using service profiles, and service flow management (SFM) has responsibility for creation, modification, and deletion of service flow. The MBS sync controller and the MBS upper/lower sync executer are used for synchronized packet delivery from ASN-GW to one or more BSs in same MBS zone. The MBS sync controller is responsible for interacting with the MBS distribution DPF to specify synchronization rules, including a time stamp for macro diversity. It also delivers MBS sync rules to the MBS sync executer. The MBS upper sync executer constructs MAC PDUs and packages them as a MAC burst based on the sync rule received from the MBS sync controller. The MBS lower

sync executer is responsible for constructing the final PHY burst, which corresponds to the MCID(s) in the given MBS permutation zone. It delivers mapping information about MCIDs to the corresponding MBS zone IDs and broadcasts MBS_MAP_IE, MBS_MAP, and MBS_DATA_IE, including the MBS zone ID and MCID [4]. The location of the MBS upper sync executer for type-1 and type-3 is different; therefore, the respective MBS data packages and delivery processes are different. In type-1 architecture, the MBS distribution DPF encapsulates the MBS content into a GRE packet. The encapsulated payload is an IP datagram, with tunneling mechanism based on GRE, including use of a sequence number. Then, the GRE packet is forwarded to the MBS upper sync executer through MBS DPF in the corresponding BSs for processing of MAC bursts. In type-3 architecture, the MBS distribution DPF classifies the packets and forwards them to the sync controller to generate the rules and, from there, to the MBS upper sync executer to generate the MAC burst that contains one or more MAC PDUs. The GRE payload including MAC bursts is delivered to the MBS lower sync executer at the BS. Type-3 architecture also uses the GRE tunneling mechanism, but the tunnel is shared by all MCIDs. In type-4 architecture, the MBS sync rule information is pre-configured in the BSs and then does not need to manage service flow. Thus, service flow functions and sync functions are removed, as shown in Fig. 2 (c), but the sync info header with only a sequence number is added to the GRE payload. The MCBCS data packaging process for type-4 architecture is the same as that for type-3. Regardless of type architectures, a GRE payload, including protocol header, does not exceed MTU size. However, when the sum of data size is greater than the MTU size, fragmentation occurs. Fig. 3 shows the details of processing and packaging MCBCS data according to the type of architecture.


For the type-1 data path, the MCBCS scheduler puts the SDUs for MCID into the GRE tunnel. If the GRE payload size for an MCID is greater than MTU size, fragmentation occurs. On the other hand, for the type-3 data path, the MCBCS scheduler makes the MAC burst from even-sized MAC PDUs for all MCIDs, then puts them into the shared GRE tunnel [7]. As shown in Fig. 3, there are SDUs with a size of a, b, and c. If the sum of sizes a, b, and c is greater than MTU size, the number of fragmentations can be obtained by calculating the sum of the quotient f_no divided by (a + b + c) to MTU size, plus 1. Hence, (f_no + 1) fragmented MAC bursts are transmitted through the GRE tunnel. These different types of MBS traffic payloads may affect the performance of media delivery.

1335

in data packaging when the Fe-GW delivers the MBS data to the WFAP. The type-4 performs the same data packaging process as type-3 but it is no different from other types in a combined femto model because all the MBS sync functions and DPF are located in same physical entity.

Fig. 4 Combined femto model

Fig. 3. Comparison of MCBCS data processing and delivery mechanisms for type-1, type-3, and type-4

III. MCBCS MODELS OVER FEMTOCELL SYSTEMS To deliver MCBCS content from the MCBCS server to the Fe-GW, an R3 interface is used, even though an Fe-GW has an R4 interface with the macro ASN-GW, because each femtocell organizes a unique MBS zone independent of the macro MBS zone. Also, deployment of MBS sync function and MBS distribution DPF depend on MCBCS architecture type and the physical location of the Fe-GW. In this section, we therefore classify two femto models for MCBCS support that depend on deployment of the Fe-GW: combined and separated femto models. We also investigate the MCBCS architecture types applied to these models. A. Combined Femto Model A combined femto model means that the femto-AP has the functions of the WFAP and the Fe-GW, as shown in fig. 4. Thus, MCBCS content over RTP/IP is delivered from the MBS server to the WFAP without distinguishing between type-1 and type-3. That means an MBS sync controller located on the WFAP generates sync rule information from received MBS contents, but upper/lower sync executer functions applying the sync rule are also located in the WFAP as the same entity. They follow the MBS data processing method depending on type of architecture, but they have no differences

B. Separated Femto Model In the separated femto model, an MBS sync controller and MBS upper sync executer are located at the Fe-GW, and an MBS lower sync executer is operated at the WFAP, as shown in Fig. 5. When we apply type-1 architecture to the separated femto model, the IP payload is delivered to the WFAP through an individual GRE tunnel for MCID. But in type-3 architecture, MAC bursts, which are composed of one or more MCIDs, are delivered to the WFAP through a shared GRE tunnel. In type-4 architecture, the MBS DPF within the Fe-GW receives MCBCS content from the MCBCS server and then generates a MAC burst containing one or more MAC PDUs. Type-4 has the same data packaging operation as type-3. When the burst size is larger, transmission overhead of type-3 and type-4 caused by link errors can be larger than that of type-1. From the perspective of buffer size required in the WFAP, type-3 needs more buffer than type-1 because the delivery of packets with several MCIDs has a greater probability of error in the same link conditions.

Fig. 5. Separated femto model

1336


IV. PERFORMANCE ANALYSIS AND RESULTS This section analyzes the performance of combined and separated femto model in terms of data overhead and buffer size required in the WFAP. We consider only the separated WFAP femto model for the comparison according to type of architecture. Because combined femto model has all sync functions at the WFAP, there is no difference of packet delivery mechanism. Buffer size in the WFAP means the size of the marginal buffer that can provide seamless broadcasting for MSs until the completion of data path recovery for errors or lost GRE packets among received GRE packets. For type-4 architecture, retransmission due to error packets is not allowed because it uses the IP multicast method. Therefore, type-4 needs no additional buffer and we consider transmission overhead only for type-4 architecture. To recover the loss of MBS data, the MBS data path recovery mechanism is used, as shown in Fig. 6, which uses the GRE tunnel sequence number of error or lost packets [4]. The MBS DPF in the WFAP sends an MBS_Data_Recovery_ Request to the MBS distribution DPF in the Fe-GW. The request contains MBS service flow identity and a list of the lost packets (identified by GRE sequence numbers). Then, the MBS distribution DPF may send an MBS_Data_Recovery_ Response message providing the size of the requested packets. Finally, the MBS distribution DPF retransmits the error or lost packets.

second playback, smpeg4 is frame rate (bytes/seconds), Tavg is average retransmission time for the MBS data path recovery procedure, and nerror is the number of error frames among received link frames. To obtain nerror and Tavg, we calculate transmissible payload size. The defined notations are as follows: • • • • • • • •

ssdu: size of received SDU from the MCBCS server smtu : size of the largest packet an Fe-GW can transmit nfrag_t1(t3)2: number of SDU fragmentations ntrans_t1(t3): packet size that an Fe-GW can transmit to the WFAP sheader_t1(t3): header size from RTP to link layer protocol strans_sdu_t1(t3): size of SDU transmitted through the GRE tunnel smax_trans_t1(t3): size of maximum transmitted link frame sremainder_t1(t3): size of the GRE payload that is not an MTU-sized packet

Fig. 7 shows the pseudocode for calculating the size of MBS data for a GRE payload. From the pseudocode, we obtain the number of packet fragmentations and transmissible SDU sizes, which vary in received SDU size and number of MCIDs.

Fig. 6. MBS data path recovery procedure

To calculate the size of the buffer, we need to know how many error packets occurred in the transmitted packets as well as the time to complete the recovery process for error packets. We then calculate corresponding buffer size proportional to completion time. In a separated femto model, a delay variation may happen as a result of packet switching within the Fe-GW, which is negligible. We then assume that the only transmission delay is introduced by GRE payload size. For media encoding, we employ MPEG-4 format, which is suitable for mobile terminals and calculation of the buffer size required in WFAP for 1 second playback time. The buffer size for WFAP Breq is calculated as shown in (1).

Breq = nmpeg 4 ⋅ smpeg 4 ⋅ nerror ⋅ Tavg ,

(1)

where nmpeg4 is the number of MPEG-4 frames required for 1 2

. t1 and t3 means type-1 and type-3, respectively.

Fig. 7 Pseudocode for calculating the size of MBS data


if (!sremainder_t3) nremainder_t3 else nremainder_t3

1; 0;

// Calculate the number of totally transmitted link frame from Fe-GW to WFAP ntot_trans_t1 nmax_trans_t1 + nremainder_t1; ntot_trans_t3 nmax_trans_t3 + nremainder_t3; // Calculate the size of transmitted link frame bits // sitrans_sdu_t1_t3 may be smax_trans_t1(t3) or sremainder_t1(t3). stot_trans_t1 sheader_t1 + sitrans_sdu_t1; stot_trans_t3 sheader_t3 + (nmcid · sitrans_sdu_t3); Fig. 8 Pseudocode for calculating the amounts of completely transmitted link frame for 1 second MPEG-4 playback

Fig. 8 shows the pseudocode for calculating the number of completely transmitted link frames for 1 second of MPEG-4 playback, but link condition is not considered in the pseudocode. We additionally obtain frame error probability. PFER denotes the probability of error in transmitting the link frame, which can be calculated as 1-(1-PBER)k, where PBER is bit error rate probability and k is stot_trans_t1(t3), which is obtained as shown in Fig. 5. Therefore, type-1 and type-3 have different PFER because the sizes of transmitted link frames vary in strans_sdu_t1(t3) and nmcid. Also, nerror is the product of ntot_trans_t1(t3), nmcid and PFER, as follows in (2):

nerror = nmcid ⋅ ntot _ trans _ t1( t 3) ⋅ PFER .

(2)

MBS data recovery time is defined as the time until retransmission of error frames is finished from Fe-GW to WFAP, which is obtained as the packet delivery time. For example, if a packet of size lP is delivered between two nodes, the packet delivery time is equal to lP/BW, where BW is the link bandwidth. However, lP is not always the same as MTU size. Thus, we calculate average packet delivery time for both MTU-sized GRE payload and not. A protocol stack for type-1 and type-3 MCBCS data plane is (MPEG-4 / RTP / UDP / IP / GMH / GRE / IP) and (MPEG-4 / RTP / UDP / IP / GMH / GRE / IP), respectively. The GMH header is replaced by FSH or PSH in the case of fragmentation or package. Based on the size of protocol stack and fragmented number, we obtain the average MBS data recovery time. Tavg

n ⋅ s + nremainder _ t1(t 3) ⋅ sremainder _ t1(t 3) 2 ⋅ s MBS −re cov = + max_ trans _ t1(t 3) mtu BWFe−GW ~WFAP ntot _ trans _ t1( t 3) ⋅ BWFe −GW ~WFAP

, (3)

100 Retransm is sion Overhead (Kbytes)

// Check there is remainder that is not MTU-sized packet if (!sremainder_t1) nremainder_t1 1; else nremainder_t1 0;

where sMBS-recov. is the packet size of MBS data recovery request/response, as defined in Fig. 4, and BWFe-GW~WFAP is the link bandwidth from Fe-GW to WFAP. For numerical results, we assume that the MCID is 3, SDU size per MCID is 400 bytes, and link bandwidth is 100 Mbps. An MTU unit is assumed to be 1500 bytes. When we consider userplane protocol stack according to the type of architecture, the MSS size of type-1 and type-3 is 1420 and 1410 bytes, respectively; if we assume that MTU is 1500 bytes, the header sizes of GRE and RTP are 16 bytes [8][9], and FSH and PSH are 2 bytes [10], respectively. To get realistic information, we employ the statistics of MPEG-4 traces used in [11], which assumes a QCIF format with 4:1:1 chrominance subsampling and quantization into 8 bits for handheld wireless devices. We also use nframe of 25 frames/sec and smpeg4 of 3.8 Kbytes/frame, as published in the literature [11]. Type-1 Type-3 80

60

40

20

0

1

2

3

4

5 6 7 The number of MCID

8

9

10

Fig. 9 MBS data transmission overhead as the number of MCID

As shown in Fig. 9, retransmission overhead for MBS data path recovery increases as the number of MCIDs increases when BER is 10-6. Type-1 increases linearly because the SDU size per MCID and FER are not changed, but the number of GRE paths increases according to the number of MCIDs. On the other hand, type-3 has a more drastically increasing slope than type-1 as FER increases, because the size of the GRE payload becomes larger while SDU size within a single GRE payload constantly decreases. 550 Type-1 Type-3 Type-4 Completely transmitted frame size (Kbytes)

// Calculate the amounts of transmitted link frame for 1s playback time nmax_trans_t1(t3) nmpeg4 · smpeg4 / strans_sdu_t1(t3); sremainder_t1(t3) (nmpeg4 · smpeg4)) % strans_sdu_t1(t3);

1337

500

450

400

350

300

0

200

400

600

800

1000 1200 SDU size

1400

1600

1800

Fig. 10. Link frame size compared to SDU size

2000


Fig. 10 shows the size of a transmitted link frame of MPEG4 data during 1 second when the number of MCIDs is 3. SDU size is related to the number of transmissions, which consequently affects the complete transmitted frame size. When SDU size varies from 0 to 400 bytes, the Fe-GW of type-1 performs relatively inefficient data transmission because data size is relatively too small for the frame header, but the Fe-GW of type-3 transmits the aggregated data by packaging all the MCID SDUs into a single GRE tunnel. The size of the transmitted link frame in type-4 is the same as that of type-3 except that they have different sizes of packet header, but this is trivial, as shown in Fig. 10. 95.3

Buffer size required in WFAP (Kbytes)

Type-1 Type-3

95.08 95.07 95.06 95.05 95.04 95.03 95.02 95.01 95

Type-1 Type-3

95.25

95.09

Buffer size required in WFAP (Kbytes)

1338

94.99 -5 10

95.2

-6

10

-7

10 Bit Error Rate (BER)

-8

10

-9

10

Fig. 13 Size of the buffer required in WFAP according to BER (link bandwidth : 100 Mbps (Fe-GW – WFAP))

95.15

95.1

95.05

95

94.95

0

2 4 6 8 10 Transmission rate (Mbps) between Fe-GW and WFAP

12 7

x 10

Fig. 11. Size of the buffer required in WFAP, according to transmission rate

Fig. 11 shows the buffer size required in WFAP as transmission rate increases from 1 Mbps to 100 Mbps when BER is 10-5 and 10-6, respectively. As transmission rate increases, there is little difference because high transmission rates can reduce recovery time for error link frames.

Figs. 12 and 13 show the buffer size required in WFAP as BER changes from 10-5 to 10-9 when transmission rate is 10 Mbps and 100 Mbps between Fe-GW and WFAP, respectively. In Fig. 12, when BER is high, there are differences from 200 bytes to 1 Kbytes between type-1 and type-3. This is because the FER probability of type-3 is larger than that of type-1 caused by packaging all kinds of MCID SDUs. Hence, a WFAP in type-3 needs more buffer to provide flexible and reliable transmission. As transmission rate increases from 10 Mbps to 100 Mbps, the difference in additional required buffer sizes between type-1 and type-3 decreases as much as 90%, from 0.78 Kbytes to 0.078 Kbytes at 10-5 BER, and 91.2%, from 0.082 Kbytes to 0.008 Kbytes at 10-6 BER. However, when BER is less than 10-7, the buffer sizes required in WFAP converge into 94.995 Kbytes, and a WFAP analytically requires little or no additional buffer. V. CONCLUSION

96.2 Type-1 Type-3 Buffer size required in WFAP (Kbytes)

96

95.8

95.6

95.4

95.2

95 -5

10

-6

10

-7

10 Bit Error Rate (BER)

-8

10

Fig. 12 Size of the buffer required in WFAP according to BER (link bandwidth : 10 Mbps (Fe-GW – WFAP))

-9

10

Femtocells are expected to extend WiMAX service to home and office users in indoor environments. Among various WiMAX services, multicast/broadcast service (MCBCS or MBS) has several types of architecture for media delivery. To enable MCBCS for an indoor environment, we presented the applicable WiMAX MCBCS architecture in a femtocell environment with combined and separated femto models. In addition, the performance characteristics of type-1, type-3, and type-4 architectures, such as the transmission overhead and the buffer size required in data packaging, were compared using real media encoding and network parameters. In the combined femto model, the WFAP and the Fe-GW are co-located, enabling flexible management of MBS resources for home users. The combined femto model has no differences in performance among the various types of architecture; however, in the separated femto model, it is necessary to separate the MBS sync function and the DPF function, which results in


different performance for each type. The numerical results show that type-3 and type-4 have more overall transmission overhead than type-1, and type-3 requires more buffers than type-1 because the FER of type-3 is larger than that of type-1, caused by the aggregated transmission of SDUs. These values can be reduced when the error rate between Fe-GW and WFAP decreases. ACKNOWLEDGMENT This research was partially supported by the MKE (The Ministry of Knowledge Economy), Korea, under the “Program for CITG” support program supervised by the NIPA (National IT Industry Promotion Agency) (NIPA-2010-0004), and by the Ubiquitous Computing and Network (UCN) Project, Knowledge and Economy Frontier R&D Program of the MKE in Korea as a result of UCNs subproject (10C2-C1-20S). REFERENCES [1] [2] [3]

[4]

[5]

[6]

WiMAX Forum, WiMAX SPWG, "Requirements for WiMAX Femtocell Systems, Version 1.0.0," April 2009. WiMAX Forum, "Network Architecture: Femtocells (Stage 2/3) in Release 1.6," (draft), September 2009. S. Yeh, S. Talwar, S. Lee, and H. Kim, "WiMAX Femtocells: A Perspective on Network Architecture, Capacity, and Coverage," IEEE Communications Magazine, vol. 46, no. 10, pp. 58-65, October 2008. WiMAX System Requirements, Network Protocols and Architecture for Multi-cast Broad-cast Services Dynamic Service Flow Based (MCBCSDSx), Part of Network Release 1.5, May 2009. WiMAX Forum Network Architecture, System Requirements, Network Protocols and Architecture for Multi-cast Broad-cast Services (MCBCS Application Layer Approach), DRAFT-T33-113-R015v01-B (Working Group Approved Specification), March 2009. K. Etemad and L. Wang, "Multicast and Broadcast Multimedia Services in Mobile WiMAX Networks," IEEE Communication Magazine, vol. 47, no. 10, pp. 84-91, October 2009.

1339

[7]

Q. Wu, K. Josiam, and J. Shim, "Proposed Text for E-MBS Control Information Elements," IEEE C802.16m-09/2172, Septempber 2009. [8] G. Dommety, “Key and Sequence Number Extensions to GRE,” IETF RFC 2890, September 2000. [9] Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, and H. Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams," IETF RFC 3016, November 2000. [10] IEEE 802.16-2009,” IEEE 802 Part 16: Air Interface for Broadband Wireless Access Systems,” IEEE Std 802.16TM-2009, May 2009. [11] F. H. P. Fitzek and M. Reisslein, "MPEG-4 and H.263 Video Traces for Network Performance Evaluation," TKN-00-06, TU Berlin, Dept. of Electrical Eng., October 2000.

BIOGRAPHIES Seil Jeon received the B.E. and M.S. degrees in electrical and communication engineering from Soongsil University, Korea, in 2006 and 2008. He is currently a Ph.D. candidate in electrical and communication engineering at Soongsil University. His current research interests include mobile communication over IP network, IP mobility management for multimedia services in broadband wireless networks, multicast/broadcast services in WiMAX networks, and Peer-to-Peer (P2P) streaming mechanism for IPTV. Younghan Kim (corresponding author) received the B.S. degree in electronic engineering from Seoul National University, Korea, in 1984. He received the M.S. and Ph. D. degrees in electrical engineering from KAIST, Korea, in 1986 and 1990, respectively. From 1987 to 1994, he worked for Digicom Institute of Telemetics as a senior research engineer, where he developed ISDN and packet switching systems. Since 1994, he has been a professor in the School of Electronics at Soongsil University in Korea. His research interests include wired and wireless networking, QoS, mobile computing and ubiquitous networking. He is a member of IEICE and IEEE.