Traitement en cours

Veuillez attendre...

Paramétrages

Paramétrages

Aller à Demande

1. WO2004064424 - SYSTEME DE SERVICE DE PAQUETS ET PROCEDE DE COMMANDE DE LA TRANSMISSION PAR PAQUETS

Note: Texte fondé sur des processus automatiques de reconnaissance optique de caractères. Seule la version PDF a une valeur juridique

[ EN ]

PACKET SERVICE SYSTEM AND METHOD FOR CONTROLLING PACKET
TRANSMISSION

Technical Field
The present invention relates to a communication system, and more particularly, to a packet service system and method of controlling packet transmission.

Background Art
In the world of cellular telecommunications, those skilled in the art often use the terms IG, 2G, and 3G. The terms refer to the generation of the cellular technology used. IG refers to the first generation, 2G to the second generation, and 3G to the third generation. IG is used to refer to the analog phone system, known as an AMPS (Advanced Mobile Phone Service) phone systems. 2G is commonly used to refer to the digital cellular systems that are prevalent throughout the world, and include CDMAOne, Global System for Mobile communications (GSM), and Time Division Multiple Access (TDMA). 2G systems can support a greater number of users in a dense area than can IG systems.
3G is commonly used to refer to the digital cellular systems currently being developed. Recently, third-generation (3G) CDMA communication systems have been proposed including proposals, such as cdma2000 and W-CDMA. These 3G communication systems are conceptually similar to each other with some significant differences.
A W-CDMA system is a third-generation (3G) wideband, asynchronous, spread spectrum radio interface system which uses the enhanced service potential of CDMA technology to facilitate data capabilities, such as Internet and intranet access, multimedia applications, high-speed business transactions, and telemetry. The focus of W-CDMA, as is that of other third-generation systems, is on network economy and radio transmission design to overcome the limitations of a finite amount of radio spectrum availability.

Under the currently proposed W-CDMA system standard, each of the base stations operates asynchronously. In other words, there is no universal time reference among separate base stations. In the W-CDMA system, each base station transmits a "synchronization" channel that comprises two sub-channels.
The first of the two sub-channels, the primary synchronization channel, uses a primary synchronization code that is common to all base stations. The second of the two subchannels, the secondary synchronization channel, uses a cyclic set of secondary synchronization codes. The secondary synchronization codes are not shared by other base stations that are not in the same code group. The mobile station in a W-CDMA system can acquire the synchronization channel of one or more base stations by searching for the primary synchronization code of the primary synchronization channel, and then using the timing information derived from the primary synchronization channel to process the secondary synchronization channel.
The International Telecommunications Union (ITU) originally spearheaded the 3G (Third Generation) standard for mobile communications systems, pursuant to the International Mobile Telephony 2000 (IMT2000) project. IMT2000 provides a vision for a single global standard for wireless networks perceived as the global 3G system. In a 3G system, the next generation of mobile communications systems will offer enhanced services, such as multimedia and video. The main 3G technologies include Universal Mobile Telecommunications System (UMTS) and CDMA2000.
UMTS provides an enhanced range of multimedia services. UMTS will speed convergence between telecommunications, information technology, media and content industries to deliver new services and create fresh revenue generating opportunities. UMTS will deliver low cost, high capacity mobile communications offering data rates as high as 2 Mbps under stationary conditions with global roaming and other advanced capabilities. The specifications defining UMTS are formulated by Third Generation Partnership Project (3GPP).
UMTS is a next generation mobile communication system evolving from GSM (global system for mobile communications) European standard. FIG. 1 is a block diagram of architecture of a general UMTS. Referring to FIG. 1, UMTS consists of a user equipment (UE) 100 (also referred to as a mobile station), a universal mobile telecommunications network terrestrial radio access network (hereinafter abbreviated UTRAN) 200, and a core network 300. UTRAN 200 consists of a plurality of ratio network subsystems 10a to lOn.
For instance, one radio network subsystem 10a consists of one radio network controller (hereinafter abbreviated RNC) 12 and a plurality of Nodes B 1 la and 1 lb. The Nodes B 11a and l ib are managed by the RNC 12. Each of the radio network subsystems 10b to lOn has the same construction of the above-explained radio network subsystem 10a. Nodes B 1 la/1 lb and 13a/13b receive uplink data transmitted from the user equipment 100 or transmit downlink data to the user equipment 100.
RNCs 12 and 14 allocate and manage radio resources. RNCs 12 and 14 play a role of access points to connect Nodes B 1 la/1 lb and 13a/13b to the core network 200, respectively. And, Nodes B 1 la/1 lb and 13a/13b play a role of access points to connect the user equipment 100 to UTRAN 200.
In the above-explained construction, if the user equipment 100 is being connected to a network, the RNC managing the user equipment 100 is a serving RNC (SRNC). In this case, SRNC plays a role in connecting the user equipment 100 to the core network 300. And, the SRNC allocates a radio resource appropriate for providing the user equipment with a specific service.
Services provided to the user equipment 100 through the above construction can be divided into a circuit switched service and a packet switched service. For instance, a general voice calling service belongs to the circuit switched service and a web browsing service via Internet access belongs to the packet switched service.
When the system in FIG. 1 supports the circuit switched service, RNCs 12 and 14 are connected to a mobile switching center (hereinafter abbreviated MSC) 20 of the core network 300. MSC 20 is then connected to GMSC (gateway mobile switching center) 30. GMSC 30 manages access of a voice call requested from or to an external network.
When the system in FIG. 1 supports the packet switched service, RNCs 12 and 14 are connected to a serving GPRS (general packet radio service) support node (hereinafter abbreviated SGSN) 40 and a gateway GPRS support node (hereinafter abbreviated GGSN) 50 of the core network 300.
In this case, GGSN 50 plays a role of a gateway for interworking with Internet or external network. Moreover, SGSN 40 is connected to GGSN 50 to manage mobility of the user equipment 100 and to perform a packet switch function. Interfaces for mutual communication are defined between various elements constructing the system in FIG. 1. Iu interface is defined between the RNCs 12 and 14 and the core network 300. Iu interface connected to an element in a packet switched area is defined as Iu-PS. Iu interface connected to an element in a circuit switched area is defined as Iu-CS. The UMTS shown in FIG. 1 is established to provide a variety of multimedia services guaranteeing a quality over a predetermined level.
An overall quality of service, which determines user's satisfaction for a specific service is defined as quality of service (hereinafter abbreviated QoS). QoS experienced by a user depends on various and complicated factors applied to the respective services.
High transmission rate or speed in wireless or wired line fails to satisfy user-requested QoS. Namely, transmission capacity (or speed) in all end-to-end transport paths including both of the wire and wireless lines should be guaranteed over a predetermined level as well as the transmission rate in the wireless line.

In UMTS, concepts of various bearer services are defined to guarantee QoS over a predetermined level for an end-to-end specific service. Specifically, an end-to-end specific communication service is divided into several lines (e.g., wired line, wireless line) through various network elements to be provided. Hence, data transfer service is independently defined in each line and each QoS for the defined service is guaranteed. Specifically, a bearer in charge of reliable transmission of user data in a line between the user equipment and the core network 300 is called a radio access bearer (hereinafter abbreviated RAB). RAB is implemented through a radio bearer service and an Iu bearer service.
The radio bearer service is to transmit data using Iu interface between the user equipment 100 and the RNCs 12 and 14, and the Iu bearer service is to perform data transmission between the RNCs 12 and 14 and the core network 300.
RAB should be firstly configured to provide a specific service. In configuring RAB, various parameters are set to satisfy specific QoS. MSC 20 initiates to configure RAB in the circuit switched service, whereas SGSN 40 initiates to configure RAB in the packet switched service.
The 3GPP (3rd generation partnership project) created for next generation standardization of UMTS specifies radio interface protocol architecture between user equipment and UTRAN. FIG. 2 is a diagram of radio interface protocol architecture between user equipment and UTRAN based on 3 GPP radio access network specifications.
Referring to FIG. 2, a radio interface protocol sets up, reconfigures, and releases the radio bearer services. The radio interface protocol is equipped with functions corresponding to layers 1 to 3 (LI to L3), i.e., physical, link, and network layers.
LI, i.e. physical layer, offers information transfer services to MAC sublayer and higher layers. LI offers separate transport channels to the MAC sublayer. The transport channel is characterized by how data is transferred on the radio interface. L2 consists of a medium access control (MAC) sublayer, a radio link control (RLC) sublayer, a packet data convergence protocol sublayer, and a broadcast/multicast sublayer.
The MAC sublayer offers separate logical channels to RLC, and one logical channel is characterized by a transferred information type. The MAC sublayer offers data transfer services through the logical channels. Such channels are grouped into two kinds, such as control channels for control plane information transfer, and traffic channels for user plane information transfer.
Reallocation services of radio resources and MAC parameters offer services to higher layers by the MAC sublayer. The reallocation services are performed by an execution request of RRC for changing MAC parameters and reallocating the radio resources. The MAC sublayer itself handles the resource allocation.
And, the MAC sublayer consists of various entities such as MAC-b, MAC-d, and MAC-s/sh. The RLC sublayer supports reliable data transfer services. The RLC sublayer segments protocol data units (hereinafter abbreviated PDUs) of higher layer into RLC service data units (hereinafter abbreviated SDUs) or reassembles RLC SDUs into PDUs of higher layers.
The broadcast/multicast control (hereinafter abbreviated BMC) sublayer offers broadcast/multicast transmission services in user plane. Basic functions of the BMC sublayer are storage of cell broadcast messages (CBs), radio resource request for traffic volume monitoring and cell broadcast service, scheduling of BMC messages, and delivery of BMS messages to user equipment. And, the PDCP sublayer offers transmission reception of network PDUs.
L3 includes sublayers on control plane. A radio resource control (hereinafter abbreviated RRC) layer as the lowest one of the sublayers of L3 is equipped with the following functions.

The RRC layer takes charge of establishment, reestablishment, maintenance, and release of RRC connection between UE (user equipment) and UTRAN. The RRC layer also takes charge of setup, reconfiguration, and release of radio bearers (hereinafter abbreviated RBs) on user plane. The RRC layer also takes charge of allocation, reconfiguration, and release of radio resources for RRC connection.
3GPP using the above-explained radio interface protocol architecture is trying to develop standardization specifications for the broadcast/multicast services (hereinafter abbreviated MBMS). MBMS intends to overcome such limitations of the previous cell broadcast service (CBS) as failure of supporting multicast function, restriction of supportable media data, and the like.
Hence, MBMS uses a unidirectional point-to-multipoint bearer service to simultaneously deliver multimedia data of audio, pictures, video, etc. to a multitude of UEs. MBMS is divided into a broadcast mode and a multicast mode.
In MBMS broadcast mode, multimedia data is transmitted to all UEs in a broadcast domain where broadcast services are available.
In MBMS multicast mode, multimedia data is transmitted to a specific UE group in a multicast domain where multicast services are available. In order to be provided with MBMS in multicast mode, UE should subscribe in a multicast subscription group. UE then enables to receive specific multicast data after completion of subscription.
Set up requirement information for MBMS is implemented by the configuration of RAB. Namely, for MBMS, RAB of MBMS for guaranteeing QoS exceeding a specific level should be set up between UE and core network.
MBMS uses a real-time transport protocol (hereinafter abbreviated RTP) in transmitting real-time data. The real-time data has a packet type transmitted on real time and is depicted as real-time packet in the following.

RTP is a protocol made appropriate for transmitting multimedia data having a real-time transmission attribute such as audio data, video data, etc. over a multicast or unicast network. RTP itself is unable to guarantee QoS for such a real-time service as voice service, video service, etc. Hence, MBMS further uses an RTP control protocol (hereinafter abbreviated RTCP).
Implemented for wired line communication, the RTP and RTCP have difficulty in offering services via both wire and wireless lines through the system shown in FIG. 2. Namely, direct application of the RTP and RTCP to the wireless line brings about the following problems.
First, an RTCP packet for transferring status information of the RTP packet to a data source fails to distinguish between packet loss occurring in the wire or the wireless lines. The RTCP packet checks the packet loss amount due to collision in the wired line only to monitor data flow in a network. The data source cannot determine if the packet loss occurs in the wireless line or the wired line.
In a UMTS network, the packet loss amount in the wireless line is generally greater than that in the wired line. Hence, it is highly probable that the data source commits errors in handling the transmission of subsequent RTP packets based on the RTCP packet.
For instance, the data source monitors the current situation of the network from the status information included in the RTCP packet, and changes a size of RTCP packet to be transmitted and an encoding scheme according to a result of the monitoring to reduce the loss of the subsequent packets that will be transmitted later.
The cause of the packet loss in the wired line is different from that in the wireless line. Hence, the size and encoding scheme of the RTP packet to be transmitted should be appropriately changed according to the respective causes of the wire and wireless lines. In the related art, there is no way for the data source to differentiate the packet loss cause in the wired line from that in the wireless line. Related art systems are unable to effectively perform the transmission handling and control in the wire and/or wireless networks to reduce the error occurrence during RTP packet transmission.
Further, if there are a plurality of UEs receiving services like MBMS, RTCP packets are transmitted to the data source from the respective UEs so as to bring about a problem in determining each bandwidth required for transmission of RTP and RTCP packets.
Specifically, since RTP and RTCP are protocols made appropriate for the wired line only, there exists one UE (or host) at a terminal end of the wired line. Hence, if such a point-to-multipoint communication as MBMS uses the related art RTP and RTCP without modification, there occurs a problem of assigning a bandwidth required for packet transmission to reduce efficiency of resource use.

Disclosure of Invention
A method of transferring real-time data from a data source to a mobile device in communication with a communications network having a wired communication line and a wireless communication line is provided. The method comprises receiving the realtime data from the data source over the wired communication line; determining packet loss for the wired communication line to produce control information; transmitting the control information to the data source; transmitting the real-time data to the mobile device over the wired and wireless communication lines based on the control information.
In one embodiment, the method further comprises determining quality of service data for at least one of the wired or wireless communication lines based on the control information; adjusting transmission requirements for the real-time data based on the quality of service data; adjusting transmission size of real-time data packets comprising the real-time data; and adjusting encoding mode of the real-time data. The adjusting is performed when real-time data is transmitted from the data source.

The quality of service for the wireless communication line is determined based on a first quality of service associated with the communications network segment that controls communication of real-time data from the data source to the mobile device and a second quality of service associated with the wired communication line. In one embodiment, the quality of service for the wireless communication line is determined based on first and second quality of service information.
The first quality of service information is received from the mobile device. The second quality of service information is determined based on receiving loss packet information for the real-time data communicated over the wired communication line. The first quality of service information is determined based on number of packets lost during communication of the real-time data from the data source to the mobile device over the wired and wireless communication lines. The real-time data is received and transmitted over a real-time transport protocol (RTP).
The real-time data is received and transmitted via a mobile communications network in communication with the data source. A UMTS terrestrial radio access network (UTRAN) determines the quality of service for the wireless communication line based on first packet loss information received from the mobile device and second packet loss information associated with receiving the data over the wired communication line.
In one embodiment, the UTRAN comprises a relay function module for depacketizing the real-time data received over the wired communication line to determining the second packet loss information. The relay function module packetizes the depacketized real-time data before transmitting it to the mobile device. The mobile device sends a feedback comprising the first packet loss information to the UTRAN after receiving the real-time data.

The real-time data is encapsulated in real-time transport protocol (RTP) packets transmitted over user data gram protocol (UDP). The real-time data is transported via real-time transport control protocol (RTCP).
In one embodiment, a real-time data communication system comprises a wired communication system connected to a data source; and an interface system for wirelessly connecting the wired communication system to a mobile device; wherein the interface system adjusts transmission requirements for real-time data based on first packet loss information associated with real-time data transmitted over the wired communication system.
A first quality of service is determined based on transmission of the real-time data from the data source to the interface system. A second quality of service is determined based on transmission of the real-time data from the interface system to the mobile device. The interface system comprises a relay module for processing data transmitted from the data source to the mobile device. If the data transmitted is not real-time data then the relay module does not process the data. If the data is not transmitted over real-time control protocol then the relay module does not process the data.
In one embodiment, a first quality of service is determined by the relay module by depacketizing real-time data transmitted over the real-time control protocol to determine packet loss in the wired communication system. A second quality of service is determined by the relay module based on feedback provided by mobile device about packet loss detected after receipt of real-time data by the mobile device.
The real-time data is encapsulated in - real-time transport protocol (RTP) packets transmitted over user data gram protocol (UDP). And, The real-time data is transported via real-time transport control protocol (RTCP), for example.
In yet another embodiment, a method of data communication comprises establishing a communication bearer between a data source and a mobile device over a communication network comprising wired and wireless communication segments; and adjusting transmission of the real-time data based on quality of service over the wired and wireless communication segments, when data being communicated comprises real-time data and is being transmitted over a real-time communication protocol.
A relay module determines the quality of service over the wireless communication segment by receiving feedback from the mobile device over a real-time control protocol and comparing the feed back with quality of service information for the wired communication segment. The relay module is incorporated into a communications network connecting the data source and the mobile device. A radio access bearer (RAB) is established between the communications network and the mobile device to provide the relay module with quality of service information.
In another embodiment, a method of transferring real-time data from a data source to a mobile device connected to a wired communication line by way of a wireless communication line, wherein a Universal Terrestrial Radio Network (UTRAN) acts as a communication interface between the wired and wireless communication lines is provider. The method comprises receiving the real-time data from the data source over the wired communication line; transmitting control information associated with transmission quality of real-time data over the wired communication line to the data source; and transmitting the real-time data to the mobile device over the wireless communication line based on the control information.

Brief Description of Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the principle of the invention.

FIG. 1 is a block diagram of architecture of a general UMTS;
FIG. 2 is a diagram of Radio Interface protocol architecture between user equipment and

UTRAN based on 3GPP radio access network specifications;
FIG. 3 is a diagram of UMTS for explaining real-time/non-real-time packet flow according to one embodiment of the present invention;
FIG. 4 is a diagram of protocol architecture for explaining real-time/non-real-time packet flow according to one embodiment of the present invention; and
FIG. 5 is a flowchart of a procedure of handling real-time/non-real-time packets according to one embodiment of the present invention.
FIG. 6 illustrates a block diagram of mobile station according to the preferred
embodiment of the present invention.
Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

Best Mode for Carrying Out the Invention
To aid describing the present invention, certain exemplary parameter names, values, lengths and other attributes are being used to describe the channels, messages and fix or variable identifiers communicated between mobile and base stations. It should be noted that such parameter names are for illustration purposes only, and that other names may be used to describe the same or similar function.
Referring to FIG. 3, a packet service system according to the present invention comprises a data source, a core network, a UTRAN, and a user equipment (UE). The data source is the beginning point of a wired line and the user equipment is the end point of a wireless line.

The UTRAN is an end point of the wired line as well as a beginning point of the wireless line. The user equipment is a terminal over the wireless, and the UTRAN is a radio access network providing the user equipment with access wireless to the UTRAN using a packet service offered by the data source.
The data source and the user equipment are equipped with protocol layers for real-time packet services. For instance, the data source downwardly contains an RTP layer and an RTCP layer and further contains a UDP/IP (user datagram protocol/Internet protocol) layer below the RTP/RTCP layers. The user equipment contains the above-mentioned protocol layers of the data source as well. Moreover, the data source and user equipment contain protocol layers for non-real-time packet services.
h one embodiment, the present invention is characterized in that UTRAN comprises RTP and RTCP layers over UDP/IP layer to support real-time packet services. UTRAN further supports non-real-time packet services as well. UTRAN plays a role in transferring non-real-time packets transparently.
The RTP layer of UTRAN relays real-time data sent from the data source to UE, and the RTCP layer controls transmission of the real-time data. The UTRAN further comprises a UDP/IP (user datagram protocol/Internet protocol) layer below the RTP/RTCP layers. The real-time data transmitted/received between the data source and UTRAN or between UE and UTRAN is RTP/UDP/IP packet. The corresponding RTP/UDP/IP layer extracts the received RTP/UDP/IP packet and converts it to a RTP or RTCP packet.
In the above description, it is explained that the UTRAN includes the RTP/RTCP layers over UDP/IP layer performing operations, which is for minimizing the structural alteration of the UTRAN. Specifically, the UTRAN of the present invention includes a function entity performing an operation by the RTP layer and an operation by the RTCP layer. A function entity relay function module is installed in RNC as an element of the UTRAN, in accordance with one embodiment, for example. The relay function module discerns wired line and wireless line from each other. An example of using the relay function module according to the present invention is shown in FIG. 3 and protocol architecture required for implementing the relay function module is shown in FIG. 4. Relay function modules in FIG. 3 are explained as follows. First, a plurality of relay function modules 80a to 80n provide independent operations of RTP/RTCP in each of wire and wireless lines for real-time packets such as RTP packets. In this case, the wireless line lies between UTRAN 200 and UE 100 and the wired line lies between the UTRAN 200 and a data source 70.
Second, the relay function modules 80a to 8 On are used in a system for transmitting RTP and RTCP packets like MBMS. In such a system, the relay function modules 80a to 80n generate RTCP packets carrying receiving status information of the wired line, and transmit RTP packets to the UEs 100 in the wireless section to handle RTCP packets carrying status information of the wireless line from the UEs 100.
Third, the relay function modules 80a to 80n are installed in the UTRAN 200 performing the control of packet transmission of the wireless line. The relay function modules 80a to 80n are connected to RNCs 12a to 12n of the UTRAN 200. In implementing the system, the relay function modules 80a to 80n can be installed in the RNCs 12a to 12n, respectively or installed in the UTRAN 200 to be separated from the RNCs 12a to 12n. Once the relay function modules 80a to 80n are connected to the RNCs 12a to 12n to operate, respectively, the connection thereof is achieved by 'tunneling'. Namely, the relay function modules 80a to 80n are connected to the RNCs 12a to 12n, respectively by tunneling to perform flow and handling controls of packets in the wire/wireless lines. Thus, if the relay function modules 80a to 80n are used as one element of the UTRAN 200, protocol layers executed by the relay function modules 80a to 80n to provide an efficient operation of RTCP in each line, as shown in FIG. 3, are defined as shown in FIG. 4.

RTP/RTCP corresponding to functions of the relay function modules 80a to 80n, a user datagram protocol (UDP) layer, and Internet protocol (IP) layers are further provided above radio and network access protocols of the UTRAN 200.
Operations of the relay function modules 80a to 80n are explained in the following by taking a case of installing the relay function modules 80a to 8 On in the RNCs 12a to 12n of the UTRAN 200, respectively as an example.
The relay function modules 80a to 80n generate control packets carrying reception status information for the wired line when such data packet data packets having real-time attributes as RTP packets transmitted from the data source 70 are received. The relay function modules 80a to 80n then provide the generated control packets to the data source 70.
hi one embodiment, the data source 70 regards the control packets transmitted from the relay function modules 80a to 80n as being transmitted at the ending point of each of the wire and/or wireless lines and determines bandwidths required for transmissions of data packet data packets (e.g., RTP packets) and control packets (e.g., RTCP packets), respectively.
The relay function modules 80a to 80n broadcast and/or multicast the data packets of the real-time attribute to a plurality of UEs on a downlink radio channel and then receive control packets generated from the UEs having received the data packets to acquire the reception status information of the current wireless line.
The relay function modules 80a to 80n or RNCs 12a to 12n perform the control of packet transmission on the data packets using the reception status information of the wireless line acquired from the control packets. In case that the RNCs 12a to 12n of the UTRAN 200 provide the control information of the data packets transmitted from the data source, the relay function modules 80a to 80n offer the reception status information of the wired line to the data source.

Consequently, one subject (data source) performing the control of the packet transmission from the reception status information of the wired line is independent from the other subject (RNC) performing the control of the packet transmission from the reception status information of the wireless line.
For another instance, each of the relay function modules 80a to 80n of the present invention adds the reception status information of the wireless line acquired from the control packet of the UE 100 to the corresponding control packet that will be delivered to the data source 70 and then transmits it.
In one embodiment, the packets transmitted to the UE 100 from the data source 70 are data packets of non-real-time attribute as well as the data packets of the real-time attribute. Yet, the relay function modules 80a to 80n support and control packet transmission of a data packet data packet having the real-time attribute such as RTP packets.
Accordingly, the core network 300 determines the attribute of the data packet that will be transmitted from the data source 70 and uses a specific indicator to operate the relay function modules 80a to 80n if the attribute of the determined data packet is real-time. Thus, the present invention, in one embodiment, uses the indicator so that the use of the relay function modules 80a to 80n supporting the control of the real-time packet transmission in the system for supporting both the real-time packet and the non-real-time packet transmission does not interrupt the transmission of the non-real-time packet.
In another embodiment, the present invention uses the indicator so that the use of the relay function modules 80a to 80n does not interrupt the transmission of the real-time packet when the control packet, and particularly, RTCP packet are not needed.
The core network 300 determines whether the attribute of the current data packet that will be transmitted from the data source 70 is real-time or non-real-time. The core network 300 informs the UTRAN 200 that is a termination of the wired line of the determined attribute of the data packet when a radio access bearer for the packet transmission to the UE is set up.
A packet service system according to the present invention is implemented through the protocol architecture shown in FIG. 4 and is applicable to the service of transmitting real-time data such as MBMS. The packet service system according to the present invention is applicable to a service of supporting real-time and non-real-time data simultaneously. Referring to FIG. 4, RTP is a protocol appropriate for providing a user with multimedia data (video and/or audio) having a real-time attribute using a multicast or unicast network. A packet format defined by RTP comprises an RTP media type field for expressing an RTP media type and further includes a payload containing the substantially serviced user information. The RTP media type field is for informing a type of the payload.
RTCP is a protocol for monitoring data transmission in the multicast network and performing minimal control and identification functions. Major functions of RTCP are to generate status information for distributing data to network elements belonging to the multicast network and to feed back the status information to a data source, for example. Some functions of the RTCP are related to a flow control and a congestion control of other protocols. For example, the status information feedback through the RTCP contains the information (e.g., information of an RTP packet loss amount, delay time occurring during packet transmission, etc.) of a transmission process of the RTP packet from an originating place transmitted the RTP packet to a destination receiving the RTP packet. The RTCP packet can carry the reception status information.
Once the RTCP packet for the received RTP packet is fed back to the originating place from the destination, the originating place determines data size and/or data amount and/or data coding scheme of an RTP packet that will be transmitted, using the status information included in the RTCP packet.

For example, in one embodiment of the present invention, UTRAN transfers the RTCP packet carrying the status information for the received RTP packet to the data source and a user equipment (UE) transmits the RTCP packet to the UTRAN. The RTCP packet is the control packet containing status information enabling a receiving side of the RTCP packet to perform the control of the transmission of a data packet (RTP packet) .
The UTRAN determines the data size and/or data amount and/or data encoding scheme of an RTP packet that will be transmitted to the UE using the status information included in the RTCP packet received from the UE. The data source determines the data size and/or data amount and/or data coding scheme of an RTP packet that will be transmitted to the UTRAN using the status information included in the RTCP packet received from the UTRAN.
In one embodiment of the present invention, an indicator is used for indicating whether to use the relay function module in UTRAN. The indicator is generated from a core network monitoring an attribute of a packet generated from the data source. The core network generates the indicator when a radio access bearer for a packet service originated from the data source is set up. The indicator represents the attribute of the packet generated from the data source, and is transferred to the UTRAN.
The UTRAN in one embodiment comprises RTP and RTCP layers over the UDP/IP layer for transmission of real-time packets. The relay function module is preferably operated by the indicator received from the core network. Namely, the core network executes control operations of the relay function module using the indicator. In other words, the indicator generated from the core network is a command for turning on/off the operations of the relay function module.
Referring to FIG. 3, the data source 70 enables to transfer a packet of the real-time or non-real-time attribute. In this case, the data source 70 is a server or terminal offering specific data as a packet format. The core network 300 determines the attribute of the packet to be transmitted from the data source 70 and then informs the UTRAN 200 as a termination of the wired line of the determined attribute of the packet to be transmitted. When a radio access bearer for the packet transmission between the core network 300 and the UE 100 is set up, each of the SGSNs 40a to 40n of the core network 300 informs the UTRAN 70 whether the packet to be transmitted from the data source 70 has the non-real-time or real-time attribute. The SGSNs 40a to 40n of the core network 300 use one indicator to inform the attribute of the packet to be transmitted from the data source 70. In one embodiment of the present invention, the indicator is not limited to inform the attribute of the current packet. The SGSNs 40a to 40n of the core network 300 utilizes the indicator in informing whether to use RTP/RTCP and/or the relay function modules 80a to 80n included in the UTRAN 200 as well as the attribute of the packet to be transmitted. In case that the indicator informs the attribute of the packet to be transmitted, the UTRAN 200 determines whether to use the relay function modules 80a to 80n, in accordance with the attribute of the packet indicated by the received indicator.
Moreover, when the indicator informs the UTRAN of whether to use the relay function modules 80a to 80n. The UTRAN 200 can check whether the packet to be currently received has the real-time or non-real-time attribute from the information indicated by the received indicator, for example.
In one embodiment of the present invention, the UTRAN 200 comprises the wired line device for receiving a packet from the data source 70. The control of packet transmission in the wired line is supported according to the reception status information of the wired line. The wireless line device transmits the packet to the UE 100 to perform the control of packet transmission in the wireless line according to the reception status information of the wireless line.
Preferably, the UTRAN 200 of the present invention comprises the relay function modules 80a to 80n. In one embodiment, the relay function modules 80a to 80n are installed in the RNCs 12a to 12n, respectively as shown in FIG. 3. Accordingly, the UTRAN 200 turns on/off operations of the relay function modules 80a to 80n according to the command of the indicator received from the corresponding one of the SGSN 40a to 40n of the core network 300, when the radio access bearer is setup.
Once a packet is transmitted from the data source 70, each of the GGSN 50a to 50n acts as a gateway for interworking with the network to which the data source belongs to deliver the corresponding packet to the SGSNs 40a to 40n. Each of the SGSNs 40a to 40n determines the attribute of the packet to be transmitted to the UE 100 and then delivers the indicator for informing the attribute of the corresponding packet to the UTRAN 200. If the determined attribute of the packet in real-time is good as that of the RTP packet, then the RTCP informs the data source 70 of the reception status information of the real-time packet via the core network 300, by way of being included in the indicator.
In one embodiment, the UTRAN 200 determines the attribute of the packet and/or whether to use the relay function modules 80a to 80n from the indicator delivered from the core network 300. Whether to use the relay function modules 80a to 80n can be further included in the indicator to deliver. That is, in case of providing the non-real-time packet service, the relay function modules 80a to 80n are not operated and the packet is transparently transmitted from the data source to the UE. Each of the SGSNs 40a to 40n delivers the real-time or non-real-time packet to the RNCs 12a to 12n of the UTRAN 200. The relay function modules 80a to 80n of the UTRAN 200 operate if the packet to be delivered to the UE 100 is real-time and when the RTCP is used. If non-real-time, they do not operate. If the RTCP is not used even though the packet to be delivered is real-time, the relay function modules 80a to 80n do not operate. The operation of the relay function modules 80a to 80n is controlled by the indicator received from the corresponding one of the SGSNs 40a to 40n.

For instance, when the RTP packet is transmitted from the data source 70 to the UE 100 as a final destination, the data source 70 should be able to monitor the network status as a loss amount of the RTP packet during the packet transmission via the UTRAN 200 in the middle of the wire and wireless lines. In one embodiment, the relay function modules 80a to 80n feed back the RTCP packet containing the reception status information of the wired line to the data source 70.
The RNCs 12a to 12n equipped with the relay function modules 80a to 80n, respectively transmit the packet received from the corresponding one of the SGSNs 40a to 40n to the UE by wireless line. In this case, if the service is the multicast service, the RNCs 12a to 12n transmit the packet to a plurality of UEs located in their service domain. If the packet received from the corresponding one of the SGSNs 40a to 40n is a real-time packet, the relay function modules 80a to 80n transmit the real-time packet to the UEs.
The relay function modules 80a to 80n feed back control packets (e.g., RTCP packets) containing the reception status information of the real-time packet to the data source 70 and receive control packets (e.g., RTCP packet) containing the reception status information of the wireless line from the UEs, respectively.
In one embodiment, each status information of the control packets received from the UEs is included in the corresponding one of the control packets to be fed back to the data source 70. The relay function modules 80a to 80n installed in the RNCs 12a to 12n, respectively provide the data source 70 with the reception status information of the UEs from the control packets received from the Ues.
In another embodiment, it is preferable for each control packet fed back to the data source 70 does not contain the reception status information of the wireless line, whereby the control packets (RTCP packets received from the UEs) containing the reception status information of the wireless line are handled by the RNCs 12a to 12n, respectively. The RNCs 12a to 12n determine sizes and/or amounts and/or coding schemes of packets to be transmitted to the wireless line based on the control packets received from the UEs, respectively.
In the foregoing description, it is explained that the relay function modules 80a to 80n used in discerning statuses of the wire and wireless lines in the flow of the real-time/non-real-time packets are installed in the RNCs 12a to 12n, respectively. Yet, the relay function modules 80a to 80n can be independently installed in the UTRAN 200 from the RNCs 12a to 12n. Furthermore, the RNCs 12a to 12n can be implemented to perform functions including the function of the relay function modules 80a to 80n. In an exemplary embodiment, the relay function modules 80a to 80n are installed at the RNCs 12a to 12n, respectively. Examples of transferring the indicator to the UTRAN 200 in the present invention are explained as follows.
When the relay function modules 80a to 80n are turned on/off according to a command of the indicator, and when a packet of an attribute is to be transmitted from the data source 70, the core network 300 delivers the indicator indicating the attribute of the packet to be transmitted to the UTRAN 200. Such an indicator indicates whether a packet has a realtime or non-real-time attribute and whether the control packet, such as RTCP packet, is used.
Hence, if the real-time packet is received after the indicator informing the packet transmission of the real-time attribute and the using of RTCP packet is received from the core network, the relay function modules 80a to 80n inform the data source 70 of the status information for the real-time packet in the wired line. Yet, if the indicator informing the packet transmission of the non-real-time attribute is received from the core network 300, the relay function modules 80a to 8 On are not involved in the non-real-time packet transmission at all.
The relay function modules 80a to 80n are turned off by the command of the indicator, when a non-real time packet attribute is transferred from the data source 70. The core network 300 transfers the indicator to the UTRAN 200, if the attribute of the packet to be transmitted is non-real-time or if the status information in the wired line is not requested despite that the packet to be transmitted is a real-time packet. That is, the RTCP is not used in case of real-time packet transmission. Hence, receiving one indicator informing the packet transmission of the non-real-time attribute or the other indicator informing that the status information in the wired line is not requested from the core network 300. The relay function modules 80a to 80n are not involved in the non-real-time or real-time packet transmission and are just turned off.
MBMS is supported and the relay function modules 80a to 80n determine whether to use the RTCP packet according to the command of the indicator from the core network 300, when a RTP packet is transmitted from the data source 70. The core network 300 transfers the indicator to the UTRAN 200, if the RTCP packet is used.
Hence, receiving the indicator from the core network, the relay function modules 80a to 80n offers the RTCP packet containing the status information of the wired line to the data source 70 and are not involved in other transmission, which does not use the RTCP packet, of the packet of the real-time attribute. Thus, the indicator contains the information of informing whether to use the RTCP.
Referring to FIG. 5, the data source 70 intends to transfer a real-time packet requesting status information for real-time packet transmission and a real-time or non-real-time packet failing to request the status information for the real-time packet transmission.

Once one specific packet transmission is requested from the data source 70, the core network 300 sets up a radio access bearer with at least one terminal 100 (SI 0). In the following description, it is assumed that MBMS radio access bearer is set up to provide MBMS to the corresponding terminals.
When the MBMS radio access bearer is set up, the core network 300 determines the attribute of packet data to be transmitted from the data source 70 and informs the UTRAN 200 of the determined attribute. The SGSNs 40a to 40n of the core network 200 inform the UTRAN 70 whether the packet to be transmitted from the data source 70 has the real-time or non-real-time attribute. The SGSN 40 informs the UTRAN 200 whether to use RTCP for the transmission of the real-time packet, for which the SGSN 40 uses an indicator.
In one embodiment, one indicator indicates whether the packet to be transmitted has the non-real-time or real-time attribute. This indicator is a packet attribute indicator. Another indicator of informing whether to use the RTCP for the transmission of the realtime packet is named an RTCP use/not-use indicator, for example.
Accordingly, the UTRAN 200 determines whether to use the relay function modules 80a to 80n based on the received indicator (SI 1). Subsequently, the packet of the data source 70 is transferred to the RNCs 12a to 12n of the UTRAN 200 (S12). The RNCs 12a to 12n of the UTRAN 200 have already decided whether to use the relay function modules 80a to 80n by the indicator received from the core network 300 in the process of setting up the radio access bearer. Therefore, the relay function modules 80a to 80n operate in the following two ways for a packet to be received.
First, if the packet to be received is an RTP packet using RTCP, each of the relay function modules 80a to 80n adds status information (e.g., a loss amount of RTP packet) in the wired line for the received RTP packet to an RTCP packet and feeds it back to the data source 70 (S13). In this case, the RNCs 12a to 12n offer the RTP packet received by tunneling or node-to-node communication to the relay function modules 80a to 80n, respectively.
The RNCs 12a to 12n or the relay function modules 80a to 80n transmit the received RTP packet to a plurality of terminals 100 in the wireless line (SI 4). In this case, the RTP packet transmitted to the terminals 100 is broadcasted or multicasted on downlink radio channel. Meanwhile, the data source 70 having received the RTCP packet determines data size, appropriate encoding scheme, and/or the like of an RTP packet to be transmitted based on the status information included in the RTCP packet (SI 5).
In one embodiment, the data source 70 changes routing information included in an RTP packet to be transmitted later based on the status information included in the RTCP packet so that RTP packets are prevented from flowing in elements of the core network 300 and/or the UTRAN 200 where collisions frequently take place (SI 5).
Moreover, the data source 70 regards the RTCP packets transferred from the relay function modules 80a to 80n as being transferred one by one per each wire/wireless line termination point and appropriately determines each bandwidth required for the transmissions of the RTP packet and the RTCP packet (S 15).
Meanwhile, the terminal 100 has already recognized the attribute of the packet to be received in the process of setting up the radio access bearer with the core network 300. Hence, the corresponding terminal 100 having received the RTP packets generates RTCP packet including status information such as the number of RTP packets lost during transmission in the wireless line, transmission delay time, and the like and then feeds it back to the RNCs 12a to 12n or the relay function modules 80a to 80n (S16).
The RNCs 12a to 12n or the relay function modules 80a to 80n perform transmission handling on the RTP packet transmitted to the respective terminals 100 in the wireless line based on the reception status information acquired from the RTCP packets transmitted from the respective terminals 100 in the wireless line (S 18).
In one embodiment, the RNCs 12a to 12n or the relay function modules 80a to 80n further feed back the RTCP packets received from the respective terminals 100 to the data source 70. The data source then further considers the RTCP packets fed back from the respective terminals 100 in determining the data size, appropriate encoding scheme, and/or the like of the RTP packets to be transmitted thereafter.

When a packet to be received is an RTP packet using no RTCP or a non-real-time packet, i.e. in case that the relay function module 80 is unnecessary for use, the RNCs 12a to 12n transmit the packet received via the core network 300 to a plurality of the terminals 100 in the wireless line (S18). Where RTCP itself is unused, the terminals 100 having received RTP packets take no operational action for generating RTCP packets.
Accordingly, in the description of the present invention, UTRAN including the relay function module transfers RTCP packet to the data source from a termination of wired line to preferably perform RTP and RTCP operations. Specifically, RTCP packet transmitted from each user equipment is handled in UTRAN so as not to be transferred to the data source. Hence, waste of radio resources is prevented, and the number of packets lost in collision on Internet can be accurately grasped. Therefore, the number of the lost packets can be counted, whereby it is able to appropriately control to provide a packet service.
In the present invention, since RTCP packets for controlling RTP packets are generated from the UTRAN as the end point of the wired line and the user equipment as the end point of the wireless line, respectively, it is facilitated to discern the statuses of the wire and wireless lines. Therefore, the present invention is configured to change the packet size and encoding scheme of RTP packets to be transmitted according to the respective causes of the wire and wireless lines.
For instance, the data source appropriately changes the size and encoding scheme of the RTP packet to be transmitted to reduce the loss of the RTP packet to be transmitted, whereby data transfer amount can be accurately adjusted. Moreover, the situation of the wired line is accurately grasped to efficiently control the wired line.
In the present invention, since UTRAN manages and controls the wireless line, the wireless line itself can adjust the data transfer amount and encoding scheme to be appropriate for the status of the current wireless line. In the present invention, statuses of the wire and wireless lines are separated from each other, whereby it is able to accurately judge whether the loss of the real-time data packets takes place in the wire or wireless line as well as to accurately judge the respective packet transmission delay times in the wire and wireless lines.
In the present invention, bandwidths for RTP and RTCP can be accurately determined, and the overall network can be more effectively controlled by grasping the status of the wired line. The system according to the present invention is modified to be appropriate for MBMS. MBMS uses RTP and RTCP to transmit real-time data. Hence, the present invention is more effective when the system broadcasts/multicasts real-time packets to user equipments in wireless line for MBMS.
Finally, in the present invention, when UTRAN uses the relay function module, the indicator for operational control of the relay function module is further used to improve an operational efficiency of the relay function module. Therefore, the present invention is more appropriate for a packet service satisfying specific QoS.
FIG. 6 illustrates a block diagram of mobile station according to the preferred
embodiment of the present invention.
Referring to FIG. 6, the mobile station 500 comprises a processor (or digital signal processor) 510, RF module 535, power management module 505, antenna 540, battery 555, display 515, keypad 520, memory 530, SIM card 525 (which maybe optional), speaker 545 and microphone 550.
A user enters instructional information, such as a telephone number, for example, by pushing the buttons of a keypad 520 or by voice activation using the microphone 550. The microprocessor 510 receives and processes the instructional information to perform the appropriate function, such as to dial the telephone number. Operational data may be retrieved from the Subscriber Identity Module (SIM) card 525 or the memory module 530 to perform the function. Furthermore, the processor 510 may display the instructional and operational information on the display 515 for the user's reference and convenience.
The processor 510 issues instructional information to the RF section 535, to initiate communication, for example, transmit radio signals comprising voice communication data. The RF section 535 comprises a receiver and a transmitter to receive and transmit radio signals. An antenna 540 facilitates the transmission and reception of radio signals. Upon receiving radio signals, the RF module 535 may forward and convert the signals to baseband frequency for processing by the processor 510. The processed signals would be transformed into audible or readable information outputted via the speaker 545, for example.
It will be apparent to one skilled in the art that the preferred embodiments of the present invention can be readily implemented using, for example, a suitably programmed digital signal processor (DSP) or other data processing device, either alone or in combination with external support logic.
The preferred embodiments may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The term "article of manufacture" as used herein refers to code or logic implemented in hardware logic (e.g., an integrated circuit chip, Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), etc.) or a computer readable medium (e.g., magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, firmware, programmable logic, etc.). Code in the computer readable medium is accessed and executed by a processor.
The code in which preferred embodiments are implemented may further be accessible through a transmission media or from a file server over a network. In such cases, the article of manufacture in which the code is implemented may comprise a transmission media, such as a network transmission line, wireless transmission media, signals propagating through space, radio waves, infrared signals, etc. Of course, those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope of the present invention, and that the article of manufacture may comprise any information bearing medium known in the art.

Industrial Applicability
It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention. Thus, it is intended that the present invention covers the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.