EP1709773A2 - Configuration de support radio optimisee pour voix sur ip - Google Patents

Configuration de support radio optimisee pour voix sur ip

Info

Publication number
EP1709773A2
EP1709773A2 EP05721753A EP05721753A EP1709773A2 EP 1709773 A2 EP1709773 A2 EP 1709773A2 EP 05721753 A EP05721753 A EP 05721753A EP 05721753 A EP05721753 A EP 05721753A EP 1709773 A2 EP1709773 A2 EP 1709773A2
Authority
EP
European Patent Office
Prior art keywords
daim
packet
packets
radio bearer
bearer configuration
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05721753A
Other languages
German (de)
English (en)
Other versions
EP1709773A4 (fr
Inventor
Young-Dae Lee
Seung-June Yi
Sung-Duck Chun
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020040001725A external-priority patent/KR100608844B1/ko
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of EP1709773A2 publication Critical patent/EP1709773A2/fr
Publication of EP1709773A4 publication Critical patent/EP1709773A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/1263—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H04W72/566—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
    • H04W72/569—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient of the traffic information

Definitions

  • the present invention generaly relates to wireless communications, and in particular, to an optimized radio bearer configuration for voice over Internet protocol (VoIP).
  • VoIP voice over Internet protocol
  • 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.
  • VoIP Voice over Internet Protocol
  • UMTS Universal Mobile Telecommunications System
  • 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.
  • RTP Real-time Transport Protocol
  • RTCP Real-time Transport Protocol
  • RLC Radio Link Control
  • VoIP Voice over Internet Protocol
  • IP Internet Protocol
  • PS Packet Switched
  • CS Circuit Switched
  • 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.
  • QoS Quality of Service
  • jtter i.e., delay variation
  • FER Fre Error Rate
  • the RTP Real-time Transport Protocol
  • the RTCP RTP Control Protocol
  • time stamp information is contained within each packet, thus the problems related to jtter can be solved.
  • the PER can be reduced by alowing the RTP source to perform rate control according to the reporting of any bsses in RTP packets.
  • the SIP Session Initiation Protocol
  • SDP Session Description Protocol
  • 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.
  • an improved header compression techmque, caled ROHC (Robust Header Compression) has been devebped and used.
  • the overal QoS is sul significantly bwer than that of CS domain based voice services.
  • RTP packets contain voice data
  • packets having a relatively smal size are transmitted frequently and regiiarly
  • 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.
  • 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.
  • UMTS Universal Mobile Telecommunications System
  • 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.
  • 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.
  • FIG. 1 depicts a packet fbw during VoIP communications between two end- users in a UMTS.
  • 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.
  • the RTP packets pass through the UDP (User Datagram Protocd) and IP kyers, and transferred to the radio protocd in RTP/UDP/IP format.
  • 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.
  • 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.
  • 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.
  • forward contrd e.g., informing RTP source information, contrding the RTP receiver, etc.
  • 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.
  • 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.
  • FIG. 2 depicts the architecture (structure) of the radio protocd used in UMTS.
  • Layer 1 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.
  • 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.
  • a contrd channel is used when transmitting contrd pkne data
  • a traffic channel is used when transmitting user pkne data.
  • the RLC kyer handes the guaranteeing of QoS for each RB (radio bearer) and its data transmissions.
  • 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.
  • 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.
  • TM transparent mode
  • UM unacknowledged mode
  • AM acknowledged mode
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • the RB refers to a service provided by Layer 2 for transferring data between the terminal and the UTRAN.
  • 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.
  • each RLC mode should be considered in more detail to determine which RB mode is appropriate for which RB service.
  • 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.
  • the SDU and PDU are mapped in a one-to-one retechnischship and pass through in a transparent manner, hence the name 'TM' (Transparent Mode) RLC.
  • 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.
  • UM unacknowledged mode
  • AM acknowledged mode
  • 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.
  • an indicator or identifier
  • SN sequence number alowing discernment of each PDU is required, thus a PDU header is necessary.
  • 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.
  • 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).
  • 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.
  • 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.
  • PS services can be broadly rougeified 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.
  • 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.
  • bi-directional communications are mainly used in point-to-point (p-t-p) communications, the AM RLC only empbys a dedicated bgical channel.
  • 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.
  • the AM RLC must support re-transmission functions, its structure is much more complicated than that of the TM or UM RLCs.
  • the AM RLC has a re-transmission buffer in addition to a transmitting/receiving buffer.
  • 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.
  • the AM RLC requires various types of parameters, state variables, and timers.
  • 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.
  • FIG. 3 depicts an RB architecture (structure) of the UMTS for VoIP data transmissions.
  • the RB shown in Figure 3 is formed at both the terminal and the UTRAN.
  • 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.
  • a compressor and a decompressor are formed for header compression and decompression of RTP/ RTCP packets. Disclosure of Invention Technical Problem
  • 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.
  • Figure 1 depicts a packet flow during VoIP communications between two end- users in a UMTS.
  • Figure 2 depicts the architecture (structure) of the radio protocd used in UMTS.
  • Figure 3 depicts an RB architecture of UMTS for VoIP data transmissions according to the conventional art.
  • Figure 4 depicts an RB architecture for VoIP according to an embodiment of the present invention in which bgical channel miitiplexing is applied.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a gist of the present invention is to provide a single radio bearer that uses at least two transport streams with respectivefy different characteristics
  • 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.
  • 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.
  • silence periods i.e., periods of silence in a voice signal
  • bi-directional communications have rektively bng silence periods, whereby contrd data is sent during ide periods of voice data.
  • 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.
  • RTCP packets 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.
  • 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
  • Figure 5 depicts the situation where transport channel mdtiplexing is applied.
  • 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.
  • 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.
  • the AM RLC is basicaly bi-directional it is preferably that a single AM RLC handes RTCP packets for both directions.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the splitting is performed according to a quality of service (QoS) re- quirement, and the characteristic of each packet identifies a packet type.
  • QoS quality of service
  • 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.
  • 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.
  • 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.
  • header compression is performed for the packets in the received single packet stream, prior to the separating step.
  • 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.
  • header decompression is performed for the packets in the single packet stream to be sent, after the combining step.
  • bgical channel mdtiplexing or transport channel miitiplexing is performed.
  • 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.
  • VoIP Voice over Internet Protocd
  • 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.
  • 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.
  • PDU protocd data unit
  • the first type of packets are RTP (real-time transport protocd) packets and the second type of packets are RTCP packets.
  • 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.
  • the splitter can be implemented in software, in hardware, or in a combination of software and hardware.
  • 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.
  • RTP real-time transport protocd
  • RTCP RTCP contrd protocd
  • the combiner can be implemented in software, in hardware, or in a combination of software and hardware.
  • the first packet handing entity can comprise a header decompressor that receives data packets and performs header decompression thereon.
  • the second packet handing entities are radio link contrd (RLC) entities, wherein one of the RLC entities is an unacknowledged mode (UM) RLC entity.
  • 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.
  • the UM RLC entities can be implemented in software, in hardware, or in a combination of software and hardware.
  • a first UM RLC has a transmitter to transmit packet data
  • a second UM RLC has a receiver to receive packet data
  • a third RLC entity is an acknowledged mode (AM) RLC entity.
  • AM acknowledged mode
  • the AM RLC entity can be implemented in software, in hardware, or in a combination of software and hardware.
  • 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.
  • RTP real-time transport protocd
  • RTCP RTCP contrd protocd
  • 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.
  • UM unacknowledged mode
  • AM acknowledged mode
  • the RTP packets received by the UM RLC are processed at a higher priority than the RTCP packets received by the AM RLC entity.
  • 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.
  • RTP real-time transport protocd
  • RTCP RTCP contrd protocd
  • 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.
  • transport channel mdtiplexing can be performed.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne une configuration de support radio (RB) permettant de traiter des paquets dans un support radio unique. La configuration de RB comprend une première entité permettant de diviser un flux de paquets unique reçu en au moins deux sous-flux de paquets, et au moins deux secondes entités possédant des modes respectivement différents pour un RB unique, chaque seconde entité permettant de traiter chaque sous-flux de paquets formé par la première entité. L'invention concerne également un procédé de traitement de paquets dans un RB unique consistant à recevoir un flux de paquets unique en provenance d'une couche de protocole supérieure, à déterminer une caractéristique de chaque paquet dans le flux de paquets unique, et à diviser les paquets déterminés en deux sous-flux différents, chaque sous-flux présentant des exigences de retard et/ou de taux d'erreurs différentes.
EP05721753A 2004-01-09 2005-01-08 Configuration de support radio optimisee pour voix sur ip Withdrawn EP1709773A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR1020040001725A KR100608844B1 (ko) 2004-01-09 2004-01-09 ＶｏＩＰ 서비스를 제공하는 무선통신 시스템
US53808704P 2004-01-20 2004-01-20
PCT/KR2005/000061 WO2005065060A2 (fr) 2004-01-09 2005-01-08 Configuration de support radio optimisee pour voix sur ip

Publications (2)

Publication Number Publication Date
EP1709773A2 true EP1709773A2 (fr) 2006-10-11
EP1709773A4 EP1709773A4 (fr) 2010-11-03

Family

ID=36955183

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05721753A Withdrawn EP1709773A4 (fr) 2004-01-09 2005-01-08 Configuration de support radio optimisee pour voix sur ip

Country Status (2)

Country Link
EP (1) EP1709773A4 (fr)
WO (1) WO2005065060A2 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100608844B1 (ko) 2004-01-09 2006-08-08 엘지전자 주식회사 ＶｏＩＰ 서비스를 제공하는 무선통신 시스템
WO2006014094A1 (fr) * 2004-08-05 2006-02-09 Lg Electronics Inc. Distinction de paquets de protocoles dans un systeme de communication sans fil
KR101094013B1 (ko) * 2009-12-30 2011-12-15 주식회사 팬택 사용자 단말기 및 그의 무선자원을 이용한 프레임 송수신 방법, 그리고, 기지국의 무선자원을 이용한 프레임 전송 방법
KR102156194B1 (ko) * 2013-08-08 2020-09-15 팬텍 주식회사 시스템 정보 전달 방법 및 장치
CN105578522B (zh) * 2014-10-11 2019-01-01 中国移动通信集团公司 传输控制协议确认报文段的发送方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030156578A1 (en) * 2002-02-08 2003-08-21 Bergenlid Lars Herbert Packet-based conversational service for a multimedia session in a mobile communications system

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6594699B1 (en) * 1997-10-10 2003-07-15 Kasenna, Inc. System for capability based multimedia streaming over a network
AU5920000A (en) * 1999-07-09 2001-02-13 Malibu Networks, Inc. Method for transmission control protocol (tcp) rate control with link-layer acknowledgements in a wireless point to multi-point (ptmp) transmission system
US6650650B1 (en) * 1999-09-16 2003-11-18 Ut Starcom, Inc. Method and apparatus for transmitting voice data over network structures
US7302497B2 (en) * 2000-02-08 2007-11-27 Telefonaktiebolaget Lm Ericsson (Publ) Using internet protocol (IP) in radio access network
EP1158740B1 (fr) * 2000-05-24 2009-09-16 Sony Deutschland GmbH Négotiation de la qualité de service
US6807156B1 (en) * 2000-11-07 2004-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Scalable real-time quality of service monitoring and analysis of service dependent subscriber satisfaction in IP networks
US6738353B2 (en) * 2002-03-20 2004-05-18 Sunrise Telecom Incorporated System and method for monitoring a packet network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030156578A1 (en) * 2002-02-08 2003-08-21 Bergenlid Lars Herbert Packet-based conversational service for a multimedia session in a mobile communications system

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"3GPP TR 25.862 V1.2.0 (2004-08); 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; RAB support for IMS (Release 6)" 3GPP TR 25.862 V1.2.0, XX, XX, 1 August 2004 (2004-08-01), pages 1-26, XP002372097 *
"RTP-RTCP Multiplexing" 3GPP TSG-RAN WG2 Meeting 37 29 August 2003 (2003-08-29), XP002601592 Retrieved from the Internet: URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_37/Docs/R2-031744.zip [retrieved on 2010-09-22] *
HÉCTOR MONTES ET AL: "DEPLOYMENT OF IP MULTIMEDIA STREAMING SERVICES IN THIRD-GENERATION MOBILE NETWORKS" IEEE PERSONAL COMMUNICATIONS, IEEE COMMUNICATIONS SOCIETY, US, vol. 9, no. 5, 1 October 2002 (2002-10-01) , pages 84-92, XP011093881 ISSN: 1070-9916 *
'RTPRTCP Multiplexing' 3GPP DRAFT; R2-031744, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE vol. RAN WG2, no. BUDAPEST, HUNGARY; 20030822, 22 August 2003, XP050124089 *
See also references of WO2005065060A2 *

Also Published As

Publication number Publication date
WO2005065060A3 (fr) 2005-08-25
EP1709773A4 (fr) 2010-11-03
WO2005065060A2 (fr) 2005-07-21

Similar Documents

Publication Publication Date Title
US7558247B2 (en) Optimized radio bearer configuration for voice over IP
US7839852B2 (en) Apparatus and method for radio transmission of real-time IP packets using header compression technique
JP5063781B2 (ja) 無線通信システムでアップリンクデータ及びバッファ状態報告を伝送する方法及びこれを具現する無線装置
TWI415433B (zh) 雙向無線電連結控制非持久模式低延遲服務
EP2763361B1 (fr) Procédé de transmission de message de protocole internet (ip), capacité d'économie de largeur de bande négociée et économie de largeur de bande de réseau
EP2375651B1 (fr) Méthode pour la reprise de décompression d'en-tête de paquets dans un système de service multimédia de diffusion/multi-diffusion
US20130294283A1 (en) Facilitating device-to-device communication
JP2000224261A (ja) ネットワ―ク層プロトコルを直接サポ―トするデ―タリンク制御プロトコルおよび方法
EP2203990B1 (fr) Procédé de fourniture de service de commutation de circuits (cs) utilisant un accès par paquets en liaison descendante haut débit (hsdpa) ou un accès par paquets en liaison montante haut débit (hsupa)
CN101449545A (zh) 使用抖动缓冲器通信及处理voip数据包的方法和系统
JPWO2007129626A1 (ja) 基地局、移動局及び通信方法
EP2127298B1 (fr) Suppression d'en tête dans un réseau de communication sans fil
JP2010518742A (ja) 制御メッセージと音声ペイロードとを分別する方法及び装置
KR20090087773A (ko) 이동 통신 시스템에서 패킷 데이터 유닛의 재전송 및 상태보고 장치 및 방법
EP1709773A2 (fr) Configuration de support radio optimisee pour voix sur ip
US7756108B2 (en) Transmission of voice over a network
KR20080018055A (ko) 패킷 데이터 송수신 방법 및 장치
US8391284B2 (en) Usage of feedback information for multimedia sessions
JP4744457B2 (ja) 通信方法および通信装置
KR101404858B1 (ko) 이동통신 시스템에서 단말이 음성 패킷 상태를 전송하는방법 및 장치
JP5033603B2 (ja) 無線通信端末、無線基地局及びパケット通信方法
KR101341752B1 (ko) 이동 통신 시스템에서 블라인드 디코딩 방법 및 장치
KR20080011868A (ko) 이동통신 시스템에서 패킷 서비스를 위한 패킷 디코딩정보의 송수신 방법 및 장치
KR20080094417A (ko) 무선 통신망을 이용한 실시간 멀티미디어 서비스에서 망상황 정보 전송 방법 및 장치
KR20120032129A (ko) 무선링크에 최적화된 헤더압축장치 및 그 방법

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060727

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/06 20060101ALI20100922BHEP

Ipc: H04L 12/66 20060101AFI20050830BHEP

A4 Supplementary search report drawn up and despatched

Effective date: 20101004

17Q First examination report despatched

Effective date: 20110307

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150414