EP1709773A2

EP1709773A2 - Optimized radio bearer configuration for voice over ip

Info

Publication number: EP1709773A2
Application number: EP05721753A
Authority: EP
Inventors: Young-Dae Lee; Seung-June Yi; Sung-Duck Chun
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2004-01-09
Filing date: 2005-01-08
Publication date: 2006-10-11
Also published as: WO2005065060A2; EP1709773A4; WO2005065060A3

Abstract

A radio bearer (RB) configuration to process packets in a single radio bearer. The RB configuration comprising: a first entity to split a received single packet stream into at least two packet sub-streams; and at least two second entities having respectively different modes for a single RB, each second entity to process each packet sub-stream split by the first entity. A method of processing packets in a single RB, comprising: receiving a single packet stream from an upper protocol layer; determining a characteristic of each packet in the received single packet stream; and splitting the determined packets into two different sub-streams, each sub-stream having different delay and/or error rate requirements.

Description

Description OPTIMIZED RADIO BEARER CONFIGURATION FOR VOICE OVER IP Technical Field

[1] The present invention generaly relates to wireless communications, and in particular, to an optimized radio bearer configuration for voice over Internet protocol (VoIP). Background Art

[2] The present invention relates to effectively providing VoIP (Voice over Internet Protocol) in a wireless environment, which is an IP (Internet Protocol) based voice service in a UMTS (Universal Mobile Telecommunications System), which is a European type IMT-2000 system. In partictiar, the present invention relates to configuring a radio bearer that is optimized for VoIP, by transmitting RTP (Real-time Transport Protocol) packets and RTCP (RTP Control Protocol) packets, which are used in providing VoIP services, via RLC (Radio Link Control) entities that have respectively different modes according to respective packet characteristics, such that the QoS (Quality of Service) for VoIP can be improved.

[3] Voice over Internet Protocol (VoIP) refers to a service for transmitting voice data via an Internet Protocol (IP), to thus provide voice data in a PS (Packet Switched) domain instead of the conventional CS (Circuit Switched) domain. The advantage of VoIP, when compared to CS domain based voice services that transmit data while maintaining an end-to-end connection, is that network resources may be used very effectively because data transmissions occur in a connection4ess state (i.e., without having to maintain an end-to-end connection). As communications techncbgies continue to devebp, the amount of user data is also increasing rapidy. Thus, for effectively using network resources, the maprity of conventional CS domain based services are now being replaced by PS domain based services. VoIP has been devebped in this context, and it is expected that for practicaly al communications systems in the future, voice communications services wfll be provided through VoIP.

[4] Although VoIP has the advantage of effectively using network resources, the disadvantage is that its QoS (Quality of Service) is bwer than that of conventional CS domain based voice services. There are many factors that affect the QoS, inciiding delay, jtter (i.e., delay variation), FER (Frame Error Rate), etc. to name a few. When VoIP was first devebped, its QoS was drasticaly bwer than that for CS domain based voice services. However, due to much research and devebpment, for wired (wireline) interface VoIP and for CS domain based voice services, the QoS of almost the same level can be guaranteed.

[5] Through the research and devebpment of wired interface VoIP, the RTP (Real-time Transport Protocol) that can effectively provide PS domain based voice services was devebped. Also, the RTCP (RTP Control Protocol) that functions to provide feedback for RTP packet transmissions was devebped. In RTP, time stamp information is contained within each packet, thus the problems related to jtter can be solved. In RTCP, the PER can be reduced by alowing the RTP source to perform rate control according to the reporting of any bsses in RTP packets. In addition to the RTP and RTCP, the SIP (Session Initiation Protocol) and SDP (Session Description Protocol), etc. have also been devebped for maintaining an end-to-end virtual connection.

[6] As such, for wired interface VoIP, the QoS can be guaranteed to a level that is currently satisfactory, but for radio (wireless) interface VoIP, the QoS is significantly bwer than that of CS domain based voice services. To increase the transmission efficiency for radio interface VoIP, an improved header compression techmque, caled ROHC (Robust Header Compression) has been devebped and used. However, the overal QoS is sul significantly bwer than that of CS domain based voice services.

[7] The greatest problem in supporting VoIP in the radio interface is that when RTP a nd RTCP packets (that are provided as a single stream in the wired interface) are also provided as a single stream in the radio interface, the QoS is decreased because their packet characteristics are respectively different. Namely, RTP packets, being real-time user data, are tderant to errors but are sensitive to delays and jtter. RTCP packets, being contrd data, are tderant to delays and jtter but are sensitive to errors. Also, because RTP packets contain voice data, packets having a relatively smal size are transmitted frequently and regiiarly, and because RTCP packets contain contrd data, packets having a size that is quite large compared to RTP packets are transmitted infrequently and irregtiariy . If RTP packets and RTCP packets having respectively different characteristics are provided as a single stream in the radio interface, the QoS wfll decrease drasticaly in a wireless (radio) environment, which has much more inferior conditions than a wired environment.

[8] Basicaly, a radio protocd handes the guaranteeing of the QoS in the radio interface for a particular service. The radio protocd differs according to the communications system, and the present disdosure wfl describe an asynchronous IMT-2000 system, namely, a UMTS (Universal Mobile Telecommunications System) based radio protocd. In UMTS, a RB (Radio Bearer) service is used for providing a particular service in the radio interface. The RB service is a service that the first and second layers (Layers 1 and 2) provide to the upper layers in a radio protocd. Currently, in UMTS, a physical (PHY) layer, a medium access contrd (MAC) layer, a radio link contrd (RLC) layer, and a packet data convergence protocd (PDCP) layer are defined. The radio protocd layers directly effect the QoS of the radio interface, and because the radio interface has much more inferior conditions than the wired interface, it can be said that the radio protocd layers effect the overal end-to-end QoS. The radio protocds also p y a maj)r rde in the transmission of RTP and RTCP packets, thus the transmission of RTP and RTCP packets in the radio interface wϋ be considered in more detail.

[9] Figure 1 depicts a packet fbw during VoIP communications between two end- users in a UMTS. First, the voice data of End User 1 is sent to the RTP/RTCP via a codec protocd kyer, and these voice data are incbded in the RTP packets. Then, the RTP packets pass through the UDP (User Datagram Protocd) and IP kyers, and transferred to the radio protocd in RTP/UDP/IP format. In the radio protocol the PDCP kyer first receives these packets and performs header compression thereon. Thereafter, the header compressed RTP/UDP/IP packets go through the RLC, MAC, and PHY kyers, and then transmitted through the radio interface. The wired network decompresses the compressed RTP/UDP/IP packets via the PHY/MAC/RLC/PDCP kyers, which are peer entities to the radio protocd of End User 1.

[10] In the wired interface, packets in RTP/UDP/IP format are transferred to the destination, and for transferring to the End User 2, the packets must go through the radio protocd once again. The RTCP packets are generated by the end user receiving the RTP packets. In general, to provide feedback regarding the bss of RTP packets, transmissions are performed in a reverse direction from that of RTP packets, but in case of forward contrd (e.g., informing RTP source information, contrding the RTP receiver, etc.), transmissions can be performed in the same direction as that of RTP packets. Generaly, as VoIP pertains to bi-directional communications between two end users, there are usualy two RTP/RTCP flows that are transmitted in respectively different directions.

[11] The RTP/RTCP packet transmissions in the radio (wireless) interface are handed by the PDCP7RLC/MAC/PHY kyers, as described previously. It should be noted that these radio protocds provide not only RTP/RTCP packet transmissions, but also provide radio interface services for al services provided in UMTS. Radio protocds exist in pairs at each end of the radio interface, namely at a terminal and at a UTRAN (UMTS Terrestrial Radio Access Network), and operate in a peer-to-peer manner. In other words, the radio protocd kyers in the terminal and those in the UTRAN have the same architecture (structure), and thus the architecture of only one of these portions (in the terminal or the UTRAN) wfl be considered for simplification.

[12] Figure 2 depicts the architecture (structure) of the radio protocd used in UMTS. Regarding each kyer of the radio protocd Layer 1 (PHY kyer) provides information transfer service to an upper kyer by using various radio transmission techniques, and is connected with the MAC kyer thereabove via a transport channel through which data is transmitted between the MAC and PHY kyers. In Layer 2, the MAC, RLC, PDCP, and BMC kyers exist. The MAC kyer provides the re-alocation service of MAC parameters for alocation and re-alocation of radio resources, and is connected with the RLC kyer (an upper kyer) via a bgical channel whereby various bgical channels are provided according to the type of data being transmitted. In general a contrd channel is used when transmitting contrd pkne data, while a traffic channel is used when transmitting user pkne data.

[13] The RLC kyer handes the guaranteeing of QoS for each RB (radio bearer) and its data transmissions. As the RB service is a service that Layer 2 of the radio protocd provides to the upper kyers, the entire Layer 2 effects the QoS, but the effect of the RLC is especialy krge. For guaranteeing the QoS that is unique to the RB, the RLC has one or two separate (independent) RLC entities for each RB, and three types of RLC modes (TM: transparent mode, UM: unacknowledged mode, and AM: acknowledged mode) for supporting various QoS. Each of these RLC modes operate differently because each supports different QoS, and their detailed functions are also respectively different. The RLC empbys these independent RLC entities and various RLC modes in order to support the QoS that is appropriate for each RB.

[14] The PDCP kyer is bcated above the RLC kyer and empbys IP packets under IPv4 or IPv6 so that the transmitted data can be effectively transmitted in the radio interface that has a rektivery smaler bandwidth. To achieve this, the PDCP kyer performs the function of minimizing the amount of any unnecessary contrd information used in the wired network. This function is caled header compression, which alows transmission of only required information in the data header such that transmission efficiency in the radio interface is increased. The PDCP kyer, because header compression is a basic function, only exists in the PS domain, and one PDCP entity exists for each RB to provide effective header compression function for each PS service.

[15] Also in Layer 2, a BMC (Broadcast/Multicast Contrd) kyer exists above the RLC kyer and handes the scheduling of eel broadcast messages to perform the function of broadcasting to terminals bcated within a partictiar ce\ but is not invdved with the transmission of RTP/RTCP packets.

[16] The RRC (Radio Resource Contrd) kyer, bcated at the bwermost portion of Layer 3, is only defined in the contrd pkne and handes the contrd of transport channels and physical channels rekted to the establishing, re-establishing, and releasing of radio bearers (RBs). Here, as described previously, the RB refers to a service provided by Layer 2 for transferring data between the terminal and the UTRAN. In general the establishing of the RB refers to the setting of the characteristics of the radio protocd kyers and channels for providing a particular service, and also refers to the procedures in setting the individual partictiar parameters and operation methods.

[17] As described above, there are three operation modes for the RLC kyer, each of which operates differently. Each RLC mode should be considered in more detail to determine which RB mode is appropriate for which RB service.

[18] First, the TM RLC mode is a mode in which no overhead is attached to the RLC SDU (Service Data Unit) received from an upper kyer when constituting a RLC PDU (Protocd Data Unit). The TM RLC was basicaly devebped for the purpose of processing voice data of the CS domain, whereby the RLC SDU size is fixed, thus the TM RLC uses the SDU itself to constitute the PDU, which is then transmitted. Namely, in TM RLC, the SDU and PDU are mapped in a one-to-one rektionship and pass through in a transparent manner, hence the name 'TM' (Transparent Mode) RLC.

[19] Unlike the transparent mode, the mode in which an overhead is added at the RLC is caled non-transparent mode, which has two types: unacknowledged mode (UM) that does not have transmission data reception confirmation reply, and acknowledged mode (AM) that has such reply.

[20] The UM and AM RLCs were devebped for the purpose of handing PS domain data, whereby the RLC SDU size may vary for each packet due to the characteristics of the PS domain data, and thus the SDUs undergo segmentation and concatenation to form PDUs having uniform size. To support the segmentation and concatenation of SDUs, an indicator (or identifier) indicating the boundary of the SDUs inokded in the PDU and a sequence number (SN) alowing discernment of each PDU is required, thus a PDU header is necessary.

[21] The UM RLC transmits upon forming a PDU by attaching a header that inokdes information regarding the concatenation and segmentation of SDUs, and this mode is appropriate for real-time PS services, such as VoIP or PS streaming. Like UM RLC, the AM RLC form a PDU by attaching a PDU header, but unlike UM RLC, the receiving side (receiver) sends an acknowledgement for the PDU transmitted by the transmitting side (transmitter). In AM RLC, the reason for replying by the receiving side is to request re-transmission by the transmitting side for those PDUs not received, and this feature of re-transmission is the maj)r characteristic of the AM RLC. Accordingly, the purpose of the AM RLC is to guarantee error-free data transmissions by performing re-transmissions, and thus the AM RLC handes the transmission of non- real-time packet data, such as TCP/IP in the PS domain. Thus, PS services can be broadly dassified into those using the UM RLC for services in which dekys are important and using the AM RLC for services in which error rates are important.

[22] Considering the communication directions, TM and UM RLCs are used in unidirectional communications, while AM RLC is used in bi-directional communications because feedback from the receiving side exists. As such bi-directional communications are mainly used in point-to-point (p-t-p) communications, the AM RLC only empbys a dedicated bgical channel. There are also structural differences, whereby TM and UM RLCs have one structure in which a single RLC entity either only transmits or only receives, but for AM RLC, both a transmitting side (transmitter) and a receiving side (receiver) exist in a single RLC entity.

[23] In particular, because the AM RLC must support re-transmission functions, its structure is much more complicated than that of the TM or UM RLCs. For managing re-transmissions, the AM RLC has a re-transmission buffer in addition to a transmitting/receiving buffer. Also, many other functions are performed, such as using a transmitting/receiving window for flow contrd performing poling by the transmitting side to request status (state) information from the peer RLC entity of the receiving side, sending a status report by the receiving side to report its buffer state to the peer RLC entity of the transmitting side, using a status PDU for carrying status information, performing a piggyback function to insert the status PDU into the data PDU in order to increase data transmission efficiency, and the like. Also, to support these functions, the AM RLC requires various types of parameters, state variables, and timers.

[24] As VoIP is a PS voice service, the UM RLC is used to transmit and because it is a bi-directional service, two UM RLCs are connected to a single PDCP to alow data having respectively different directions to be transmitted.

[25] Figure 3 depicts an RB architecture (structure) of the UMTS for VoIP data transmissions. To support VoIP, the RB shown in Figure 3 is formed at both the terminal and the UTRAN. Because VoIP is a bi-directional service, the UTRAN provides two RTP/RTCP flows in respectively different directions. The RB for VoIP consists of one PDCP entity and two UM RLC entities, whereby each UM RLC entity operates in respectively different directions. The MAC and PHY are kyers common to al RBs, thus a particular entity is not generated, and merely supports the mapping of bgical channels, transport channels, and physical channels. In the PDCP, a compressor and a decompressor are formed for header compression and decompression of RTP/ RTCP packets. Disclosure of Invention Technical Problem

[26] When providing VoIP services using the conventional RB architecture, the fdbwing problems exist. The RTP and RTCP packets are sent to the radio protocd via a single flow, but because the RTCP packets are much krger in size than RTP packets, the transmission of the RTP packets (that are sent to the radio protocd after the RTCP packets are sent) are dekyed while the RTCP packets are being transmitted. Unlike RTCP packets, because RTP packets are sensitive to dekys and jtter, if transmission of RTP packets is dekyed for a probnged period of time, and after the kpse of a preset time period, such RTP packets are not transmitted but discarded. Namely, when empbying the conventional method for providing VoIP services, undesirable discarding of RTP packets can occur due to the transmission of RTCP packets, which is thus a cause of degradation for QoS of VoIP, and a solution to such problems is required. Technical Solution

[27] To sdve the above-identified problems of the conventional art, the present invention provides a method of transmitting RTP and RTCP packets sent to the radio protocd via a single flow by using respectively different RLC modes according to their characteristics. Description of Drawings

[28] The features, nature, and advantages of the present invention wϋ become more apparent from the detailed description set forth bebw when taken in conjunction with the drawings in which like reference characters identify correspondingly throughout and wherein:

[29] Figure 1 depicts a packet flow during VoIP communications between two end- users in a UMTS.

[30] Figure 2 depicts the architecture (structure) of the radio protocd used in UMTS.

[31] Figure 3 depicts an RB architecture of UMTS for VoIP data transmissions according to the conventional art.

[32] Figure 4 depicts an RB architecture for VoIP according to an embodiment of the present invention in which bgical channel miitiplexing is applied.

[33] Figure 5 depicts an RB architecture for VoIP according to an embodiment of the present invention in which transport channel miitiplexing is applied. Mode for Invention

[34] The present invention provides a method in which RTP packets requiring real-time characteristics to be maintained, are transmitted through the UM RLC, and RTCP packets requiring error-free transmissions are transmitted through the AM RLC that alows for re-transmissions. Also, the PDCP in the transmitting side inokdes a function for distinguishing and transferring RTP and RTCP packets received from an upper kyer in a single flow, such that the RTP and RTCP packets are sent to RLCs of respectively different modes, while the PDCP in the receiving side inokdes a function for transferring the RTP and RTCP packets received from respectivefy different RLCs to an upper kyer via a single flow. Here, a distinguishing and transferring device (e.g., a splitter) of the PDCP and a distinguishing and receiving device (e.g., a combiner) of the PDCP are preferably bcated bebw the header compressor and header decompressor, respectivefy. This is because, by providing a single header compressor and header decompressor for both RTP and RTCP packets, the memory (storage) rekted thereto can be saved (reduced), and the signaling bad in setting (establishing) the header compressor and decompressor can be minimized. If a distinguishing and transferring device and a distinguishing and receiving device are each provided above the header compressor and above the header decompressor, this would mean that two header compressors and two header decompressors are to be used, which woiid then not achieve the above explained advantages.

[35] The present invention transmits RTP and RTCP packets through respectivefy different RLC modes, but if transmissions are performed through respectivefy different channels up to the physical channel the problem of increasing the waste of radio resources is created. Thus, the present invention provides a method by which the RTP and RTCP packets that are divided (separated) into two flows by the RLC are combined together into a single flow once again at the MAC kyer or PHY kyer and transmission is performed via a single physical channel to increase efficient usage of radio resources. Namely, multiplexing is performed on the bgical channel between the RLC and the MAC, or mdtiplexing is performed on the transport channel between the MAC and the PHY, and then transmission via a single physical channel is performed. Namely, a gist of the present invention is to provide a single radio bearer that uses at least two transport streams with respectivefy different characteristics

[36] However, when miitiplexing in the MAC or PHY, when the RTP and RTCP flows are unconditionaly multiplexed, the undesirable discarding of RTP packets due to RTCP packet transmissions may occur as in the conventional art. Accordingly, the present invention further empbys a bgical channel priority handing of the MAC empbyed in the conventional UMTS in order to hande the RTP and RTCP flow. The bgical channel priority handing of the MAC refers to a function that first transmits data of a bgical channel having high priority when bgical channel miitiplexing or transport channel miitiplexing occurs at the transmitting side. Namely, for example, a bgical channel for RTP flow is assigned a high priority and a bgical channel for RTCP flow is assigned a bw priority, and the RTCP packets are to be transmitted only when there are no RTP packets to be transmitted. This method takes advantage of the fact that human voice signals contain silence periods (i.e., periods of silence in a voice signal) and that bi-directional communications have rektively bng silence periods, whereby contrd data is sent during ide periods of voice data. Here, it shoiid be noted that the order in which the PDCP sends RTP and RTCP packets to the RLC may be different when actualy transmitting through the radio interface due to the bgical channel priority handling function. Namely, due to the transmission dekys of RTCP packets, the order of transmitting and receiving RTP and RTCP packets at both ends of the radio protocd may be changed, but because RTCP packets are contrd data that are tderant to errors but rektively sensitive to dekys, the affects of transmission dekys of RTCP packets can be said to be minimal.

[37] Figures 4 and 5 depict an RB architecture (structure) for VoIP according to an embodiment of the present invention. Figure 4 depicts the situation where bgical channel mdtiplexing is applied, and Figure 5 depicts the situation where transport channel mdtiplexing is applied.

[38] Figures 4 and 5 conceptualy depict the distinguishing and transmitting device (e.g., splitter) and the distinguishing and receiving device (e.g., combiner) of the PDCP, and these functions may actualy be performed at the header compressor and decompressor. Also, the drawings depict RTCP packets in the first direction and the second direction both being handed by a single AM RLC, but the RTCP packets may also be handed by a separate AM RLC provided for each direction, respectivefy. However, as the AM RLC is basicaly bi-directional it is preferably that a single AM RLC handes RTCP packets for both directions. Also, the drawings depict an RB architecture for a bi-directional communications VoIP service, but for a uplink dedicated or downlink dedicated uni-directiona communications service, the radio protocd woiid be formed for only one direction. For example, assuming a downlink dedicated streaming service, the UTRAN would have a transmitting side structure shown in the drawings, while the terminal (UE) woiid have a receiving side structure shown in the drawings.

[39] The RB architecture and techniques according to the present invention have many differences compared with those of the conventional art, because two UM RLC entities and a single AM RLC entity can be empbyed in a single RB. Namely, the conventional art data services were simple enough that a single RB need only empby one type of RLC mode, but such conventional RB architecture is not appropriate for handing mdtimedia data services having various QoS that need to be guaranteed. As such, the present invention was devebped such that a single RB comprises respectively different RLC modes.

[40] Also, in contrast to the conventional RB comprising one AM RLC and one or two UM or TM RLCs, the present invention provide an RB with two UM RLCs and one AM RLC for handling bi-directional services such as VoIP, and an RB with one UM RLC and one AM RLC for handling uni-directional services such as uni-directional streaming services. Because a RB identity is inokded for each RB established for the radio protocd the UM RLC and the AM RLC must have the same RB identity in order to form the RB according to the present invention. In the conventional art, respectively different RB identities are used for respectivefy different RLC modes, using the same RB identity for respectively different RLC modes as in the present invention requires modifications in the signaling methods used for establishing the RB.

[41] The present invention provides a method of processing packets in a single radio bearer, comprising: receiving a single packet stream from an upper protocd kyer; determining a characteristic of each packet in the received single packet stream; and splitting the determined packets into two different sub-streams, wherein each sub- stream has a different deky requirement and/or an error rate requirement.

[42] Preferably, the splitting is performed according to a quality of service (QoS) re- quirement, and the characteristic of each packet identifies a packet type. Preferabfy, one sub-stream is for RTP (real-time transport protocd) packets and the other sub- stream is for RTCP (RTP contrd protocd) packets. The RTP packets are transmitted through a first RLC entity and the RTCP packets are transmitted through a second RLC entity.

[43] The method can further comprise a step of performing bgical channel priority handing, which minimizes any dekys in transmitting the RTP packets by transmitting the RTP packets at a higher priority compared with the RTCP packets. Preferabfy, header compression is performed for the packets in the received single packet stream, prior to the separating step.

[44] The method can further comprise the steps of: receiving packets from two different sub-streams, wherein each sub-stream has a different deky requirement and/or an error rate requirement; combining the received packets into a single packet stream; and sending the single packet stream to an upper protocd kyer.

[45] Preferably, header decompression is performed for the packets in the single packet stream to be sent, after the combining step. Also, bgical channel mdtiplexing or transport channel miitiplexing is performed. Preferabfy, the steps of the method are for Voice over Internet Protocd (VoIP) communications, wherein the steps are performed by a terminal or the steps are performed by a network.

[46] The present invention further provides a radio bearer configuration, comprising: a first packet handing entity to split a received single packet stream into at least two packet sub-streams; and at least two second packet handing entities having respectively different modes for a single radio bearer, each second packet handing entity to process each packet sub-stream split by the first packet handling entity.

[47] Preferabfy, the first packet handing entity splits the single packet stream by checking a format field of a protocd data unit (PDU) such that packets of a first type are forwarded in a first packet sub-stream and packets of a second type are forwarded in a second packet sub-stream. Here, the checking of the format field invdves checking a field in a header of the PDU.

[48] Preferabfy, the first type of packets are RTP (real-time transport protocd) packets and the second type of packets are RTCP packets.

[49] Preferabfy, each packet handling entity is part of a radio protocd kyer, wherein the first packet handing entity is a packet data convergence protocd (PDCP) entity, and the first packet handling entity comprises a header compressor that receives data packets and performs header compression thereon. Also, the first packet handling entity comprises a splitter that splits the single packet stream into one packet sub- stream for RTP (real-time transport protocd) packets and another packet sub-stream for RTCP (RTP contrd protocd) packets. Here, the splitter can be implemented in software, in hardware, or in a combination of software and hardware.

[50] Also, the first packet handing entity comprises a combiner that combines one packet sub-stream for RTP (real-time transport protocd) packets and another packet sub-stream for RTCP (RTP contrd protocd) packets into a single packet stream. Here, the combiner can be implemented in software, in hardware, or in a combination of software and hardware.

[51] Also, the first packet handing entity can comprise a header decompressor that receives data packets and performs header decompression thereon. Here, the second packet handing entities are radio link contrd (RLC) entities, wherein one of the RLC entities is an unacknowledged mode (UM) RLC entity. Alternatively, two of the RLC entities are unacknowledged mode (UM) RLC entities, a first UM RLC entity for data service in a first direction and a second UM RLC entity for data service in a second direction. Here, the UM RLC entities can be implemented in software, in hardware, or in a combination of software and hardware.

[52] Preferably, a first UM RLC has a transmitter to transmit packet data, a second UM RLC has a receiver to receive packet data, and a third RLC entity is an acknowledged mode (AM) RLC entity. 38. Here, the AM RLC entity can be implemented in software, in hardware, or in a combination of software and hardware.

[53] Preferabfy, the AM RLC has a transmitter to transmit packet data and a receiver to receive packet data. One packet sub-stream is for RTP (real-time transport protocd) packets and the other packet sub-stream is for RTCP (RTP contrd protocd) packets. Here, the RTP packets are forwarded to an unacknowledged mode (UM) RLC entity and the RTCP packets are forwarded to an acknowledged mode (AM) RLC entity.

[54] The RTP packets received by the UM RLC are processed at a higher priority than the RTCP packets received by the AM RLC entity.

[55] Preferabfy, the UM RLC entity outputs RTP (real-time transport protocd) packets and the AM RLC entity outputs RTCP (RTP contrd protocd) packets to a bwer protocd kyer in the same packet stream, the RTP packets being output at a higher priority than the RTCP packets. Here, bgical channel mdtiplexing can be performed.

[56] Here, the UM RLC entity outputs RTP (real-time transport protocd) packets and the AM RLC entity outputs RTCP (RTP contrd protocd) packets to a bwer protocd kyer in separate packet streams, the RTP packets having a higher priority than the RTCP packets. Here, transport channel mdtiplexing can be performed.

[57] Preferabfy, the packet handing entities are for Voice over Internet Protocd (VoIP) communications, wherein the packet handing entities are part of a radio protocd of a network that alows communication between two end users. Here, the network can be a UTRAN (UMTS Terrestrial Radio Access Network), and the packet handing entities can be part of a radio protocd of an end user, such as user equipment (UE), a wireless communications device, or the like.

[58] By advantageously applying the present invention, imitimedia services having various QoS requirements can be effectively provided in the radio interface. In particular, in a service such as VoIP wherein packets for which deky time is important and packets for which error rate is important are transmitted together, the QoS that is appropriate for each type of packet can be guaranteed, and thus the present invention is helpful in improving the overal service quality.

[59] Although various aspects, embodiments, and features of the present invention have been described for UMTS, many of these techniques can be advantageously applied for other communications systems.

[60] The foregoing description of the preferred embodiments is provided to enable any person skfled in the art to make or use the present invention. Various modifications to these embodiments wfl be readily apparent to those skϋed in the art, and the generic principles defined herein may be applied to other embodiments without the use of the inventive facdty. Thus, the present invention is not intended to be limited to the embodiments shown herein but us to be accorded the widest scope consistent with the principles and novel features disdosed herein.

Claims

[I] A method of processing packets in a single radio bearer, comprising: receiving a single packet stream from an upper protocd kyer; determining a characteristic of each packet in the received single packet stream; and splitting the determined packets into two different sub-streams, wherein each sub-stream has a different deky requirement and/or an error rate requirement. [2] The method of daim 1, wherein the splitting is performed according to a quality of service requirement. [3] The method of daim 1, wherein the characteristic of each packet identifies a packet type. [4] The method of daim 1, wherein one sub-stream is for RTP packets and the other sub-stream is for RTCP packets. [5] The method of daim 4, wherein the RTP packets are transmitted through a first RLC entity and the RTCP packets are transmitted through a second RLC entity. [6] The method of daim 5, further comprising a step of performing bgical channel priority handling. [7] The method of daim 6, wherein the bgical channel priority handing minimizes any dekys in transmitting the RTP packets by transmitting the RTP packets at a higher priority compared with the RTCP packets. [8] The method of daim 1, wherein header compression is performed for the packets in the received single packet stream, prior to the separating step. [9] The method of daim 1, further comprising: receiving packets from two different sub-streams, wherein each sub-stream has a different deky requirement and/or an error rate requirement; combining the received packets into a single packet stream; and sending the single packet stream to an upper protocd kyer. [10] The method of daim 9, wherein header decompression is performed for the packets in the single packet stream to be sent, after the combining step.

[II] The method of daim 1, wherein bgical channel mdtiplexing or transport channel mdtiplexing is performed.

[12] The method of daim 1, wherein the steps are for VoIP communications.

[13] The method of daim 1, wherein the steps are performed by a terminal.

[14] The method of daim 1, wherein the steps are performed by a network. [15] A radio bearer configuration, comprising: a first packet handing entity to split a received single packet stream into at least two packet sub-streams; and at least two second packet handing entities having respectivefy different modes for a single radio bearer, each second packet handling entity to process each packet sub-stream split by the first packet handing entity.

[16] The radio bearer configuration of daim 15, wherein the first packet handling entity splits the single packet stream by checking a format field of a PDU such that packets of a first type are forwarded in a first packet sub-stream and packets of a second type are forwarded in a second packet sub-stream.

[17] The radio bearer configuration of daim 16, wherein the checking of the format field invdves checking a field in a header of the PDU.

[18] The radio bearer configuration of daim 16, wherein the first type of packets are RTP packets and the second type of packets are RTCP packets.

[19] The radio bearer configuration of daim 15, wherein each packet handling entity is part of a radio protocd kyer.

[20] The radio bearer configuration of daim 15, wherein the first packet handling entity is a PDCP entity.

[21] The radio bearer configuration of daim 15, wherein the first packet handling entity comprises a header compressor that receives data packets and performs header compression thereon.

[22] The radio bearer configuration of daim 21, wherein the first packet handling entity comprises a splitter that splits the single packet stream into one packet sub-stream for RTP packets and another packet sub-stream for RTCP packets.

[23] The radio bearer configuration of daim 22, wherein the splitter is implemented in software, in hardware, or in a combination of software and hardware.

[24] The radio bearer configuration of daim 15, wherein the first packet handling entity comprises a combiner that combines one packet sub-stream for RTP packets and another packet sub-stream for RTCP packets into a single packet stream.

[25] The radio bearer configuration of daim 24, wherein the combiner is implemented in software, in hardware, or in a combination of software and hardware.

[26] The radio bearer configuration of daim 24, wherein the first packet handling entity comprises a header decompressor that receives data packets and performs header decompression thereon. [27] The radio bearer configuration of daim 15, wherein the second packet handing entities are RLC entities. [28] The radio bearer configuration of daim 27, wherein one of the RLC entities is a UM RLC entity. [29] The radio bearer configuration of daim 27, wherein two of the RLC entities are UM RLC entities, a first UM RLC entity for data service in a first direction and a second UM RLC entity for data service in a second direction. [30] The radio bearer configuration of daim 29, wherein the UM RLC entities are implemented in software, in hardware, or in a combination of software and hardware. [31] The radio bearer configuration of daim 29, wherein a first UM RLC has a transmitter to transmit packet data, a second UM RLC has a receiver to receive packet data. [32] The radio bearer configuration of daim 29, wherein a third RLC entity is an AM RLC entity. [33] The radio bearer configuration of daim 32, wherein the AM RLC entity is implemented in software, in hardware, or in a combination of software and hardware. [34] The radio bearer configuration of daim 32, wherein an AM RLC has a transmitter to transmit packet data and a receiver to receive packet data. [35] The radio bearer configuration of daim 15, wherein one packet sub-stream is for real-time transport protocd packets and the other packet sub-stream is for RTP contrd protocd packets. [36] The radio bearer configuration of daim 35, wherein the RTP packets are forwarded to a UM RLC entity and the RTCP packets are forwarded to an AM RLC entity. [37] The radio bearer configuration of daim 36, wherein the RTP packets received by the UM RLC are processed at a higher priority than the RTCP packets received by the AM RLC entity. [38] The radio bearer configuration of daim 15, wherein the UM RLC entity outputs RTP packets and the AM RLC entity outputs RTCP packets to a bwer protocd kyer in the same packet stream, the RTP packets being output at a higher priority than the RTCP packets. [39] The radio bearer configuration of daim 38, wherein bgical channel mdtiplexing is performed. [40] The radio bearer configuration of daim 15, wherein the UM RLC entity outputs RTP packets and the AM RLC entity outputs RTCP packets to a bwer protocd kyer in separate packet streams, the RTP packets having a higher priority than the RTCP packets. [41] The radio bearer configuration of daim 40, wherein transport channel miitiplexing is performed. [42] The radio bearer configuration of daim 15, wherein the packet handling entities are for VoIP communications. [43] The radio bearer configuration of daim 15, wherein the packet handling entities are part of a radio protocd of a network that alows communication between two end users. [44] The radio bearer configuration of daim 43, wherein the network is a UTRAN.

[45] The radio bearer configuration of daim 15, wherein the packet handing entities are part of a radio protocd of an end user. [46] The radio bearer configuration of daim 45, wherein the end user comprises user equipment. [47] The radio bearer configuration of daim 45, wherein the end user is a wireless communications device.