EP1516500A1

EP1516500A1 - Method for supporting real time traffic in a mobile radio communication system

Info

Publication number: EP1516500A1
Application number: EP03757136A
Authority: EP
Inventors: Vincent Muniere
Original assignee: Evolium SAS
Current assignee: Evolium SAS
Priority date: 2002-06-11
Filing date: 2003-06-11
Publication date: 2005-03-23
Also published as: US20050169207A1; FR2840758A1; FR2840758B1; CN1659906A; WO2003105505A1

Abstract

The invention concerns a method for supporting real time traffic in a mobile radio communication system comprising a radio access network and a network core, whereby the real time traffic supported in packet mode in the network core is supported in the radio access network by allocation of dedicated channels.

Description

METHOD FOR SUPPORTING REAL-TIME TRAFFIC IN A MOBILE RADIO COMMUNICATION SYSTEM

The present invention relates generally to mobile radio systems. In general, these systems are subject to standardization, and for more information one can refer to the corresponding standards, published by the corresponding standardization bodies.

Generally, in these systems, one can distinguish different types of services, depending on the quality of service required. In particular, a distinction can be made between real-time services, corresponding to traffic sensitive to transfer delays (such as in particular voice, or even streaming traffic or “streaming”), and non-real-time services, corresponding to traffic. not sensitive to transfer delays (such as in particular data transfer).

In general, in these systems, we can also distinguish different types of services, depending on the techniques used to support them. We can thus distinguish services in circuit mode and services in packet mode. In circuit mode, traffic is transported in dedicated resources or channels permanently allocated to a user for the duration of a call. In packet mode, traffic is transported in resources or channels shared between several users. The circuit mode thus makes it possible to guarantee the transfer times for each user, but does not allow efficient use of the resources available to all of the users. On the contrary, the packet mode allows efficient use of all of the available resources, but does not guarantee transfer times. Circuit mode and packet mode are differentiated not only by different resource allocation techniques, but also by different protocol architectures.

Second generation systems, of the GSM (“Global System for Mobile communications”) type were rather designed initially to support real-time traffic (essentially voice) in circuit mode. Additional functionalities were then introduced into these systems, corresponding to the GPRS (“General Packet Radio Service”) functionality, to enable them to support non-real-time packet mode traffic. The general architecture of mobile radiocommunication systems is recalled in FIG. 1, it essentially comprises: a radio access network 1, or RAN (for “Radio Access Network”), a core network 4, or CN (for “ Core Network ”). In this general architecture, the RAN is made up of base stations 2 and base station controllers 3. It is in relation on the one hand with mobile terminals via an interface 6 also called radio interface, and on the other hand with CN 4 via an interface 7. CN 4 is in contact with external networks, not specifically illustrated, such as PSTN ("Public Switched Telephone Network"), PDN ("Packet data Network"), ... etc.

The general architecture of second generation GSM type systems is recalled in FIG. 2. In these systems, the RAN is called BSS ("Base Station Subsystem"), the base stations are called BTS ("Base Transceiver Station") , the base station controllers are called BSC ("Base Station Controller"), and the mobile terminals are called MS ("Mobile Station"). The functionalities specific to packet mode services are generally supported by a particular entity called PCU (“Packet Control Unit”), not specifically illustrated, generally provided in the BSS.

In second generation GSM type systems, CN includes: - for circuit mode, 2G-MSC type entities (where 2G is used for

"2 ^nd Generation" and MSC is used for "Mobile Switching Center"), for packet mode, entities of type 2G-SGSN (where 2G is used for "2 ^nd Generation" and SGSN is used for "Serving GPRS Support Node "). Thus, in second generation GSM type systems, the interface 7 includes an interface called interface “A” to entities of type 2G-MSC, and an interface called interface “Gb” to entities of type 2G-SGSN.

GERAN type systems (“GSM EDGE Radio Access Network”, where EDGE is used for “Enhanced Data rates for GSM Evolution”) correspond to evolutions of GSM type systems, aiming to offer third generation services, both for real-time applications only for non-real-time applications. The aim is in particular to be able to support services of the IMS (“IP Multimedia Sub-system” type, where IP is used for “Internet Protocol”). For this, it was initially proposed to align the services offered by GERAN type systems with those offered by third generation UMTS (“Universal Mobile Telecommunication System”) systems by connecting GERAN type BSSs to CN 3G via the interfaces read, said interfaces being used to connect the UTRAN (for “UMTS Terrestrial Radio Access Network) to the CN 3G.

The architecture of third generation UMTS type systems is recalled in FIG. 3. In these systems, the RAN is called UTRAN, the base stations are called Node B, the base station controllers are called RNC

("Radio Network Controller"), and the mobile terminals are called UE ("User Equipnnent").

In third generation UMTS systems, CN includes: for circuit mode, 3G-MSC type entities (where 3G is used for “3 ^rd Generation” and MSC is used for “Mobile Switching Center”), for packet mode, 3G-SGSN type entities (where 3G is used for "3" * Generation "and SGSN is used for" Serving GPRS Support

Node "). Thus, in third generation UMTS systems, the interface 7 includes an interface called the “lu-CS” interface to the entities of the 3G-MSC type, and an interface called the “lu-PS” interface to the entities of the type 3G-SGSN. The architecture initially proposed for GSM / GERAN type systems is recalled in FIG. 4. It has thus been proposed to introduce into GSM / GERAN type systems, in addition to the existing “A” and “Gb” interfaces, an “lu-CS” type interface to 3G-MSC type entities and an “lu-PS” type interface to 3G-SGSN type entities. However, it is now recognized that such an approach requires complex and costly adaptations, in particular in the layer 2 and 3 radio protocols.

This is why another approach has now been proposed, which consists in supporting the same services as those supported by means of the interfaces “lu CS”, “lu-PS” but by means of the existing interfaces “A”, “Gb” . The aim is in particular to be able to support IMS (“IP Multimedia Subsystem”) type services via the “Gb” interface. For the record, today the “Gb” interface is only capable of supporting non-real time services (possibly traffic streaming or “streaming”), and real-time services can only be supported via the “A” interface.

In general, this last approach includes the following improvements, with a view to evolving the so-called "A / Gb" mode towards a so-called "A / Gb +" mode: - multiple and parallel data flows between BSS and MS, handover (or handover) for real-time services in packet mode, real-time service support by the radio part (or RAN), real-time service support by the network part (or CN), - IMS service support , improvement of security mechanisms. Up to now, the only proposal for the support of real time services in packet mode on the “Gb” interface has been to provide for a handover or “handover” for services in packet mode. It should be remembered that the handover procedures are specific to circuit mode. According to these procedures, resources are reserved in a new cell while a mobile station is still connected to an old cell, which allows, at the cost of a certain complexity, to guarantee the transfer times. On the contrary, cell re-selection procedures are specific to packet mode. According to these procedures, resources are only allocated to a mobile station in a new cell when the mobile station is connected to the new cell, which simplifies the procedures but does not guarantee transfer times.

The proposal mentioned above makes it possible to introduce mechanisms for packet mode similar to those used in handover procedures or “handover” for circuit mode. In addition, procedures have been proposed to allow a mobile station to regularly report radio measurements to the network in order to allow the latter to select a new cell, as in circuit mode. For this, a new combination of channels on the radio interface has been proposed, in particular in the document "Tdoc G2-020553, Agenda Item 5.3, 3GPP TSG GERAN WG2 Sophia-Antipolis, France, 27-31 May 2002". This new combination consists of a channel allocated for data transfer in packet mode, or PDTCH channel (“Packet Data Transfer Channel”) and a dedicated signaling channel in circuit mode or SACCH channel (“Slow Associated Control Channel”), the latter channel being used for such a transfer of radio measurements from the mobile station to the network.

As the applicant has observed, such a proposal has the following disadvantages in particular: the base station BTS and the mobile station MS must support a new combination of channels, the entity PCU (in which the proper functionalities are implemented in packet mode) must process measurement reports and implement handover algorithms, - a new procedure must be introduced on the radio interface to support this new combination, problems arise in terms of architecture of these systems since the SACCH would use a protocol of the LAPDm type (“Link Access Protocol for the Dm channel”) as layer 2 protocol whereas the signaling channel associated with the PDTCH channel, or PACCH channel

(“Packet Associated Control Channel”), uses an RLC / MAC type protocol, these two protocols ending in different network nodes (BTS for LAPDm, PCU for RLC / MAC). Furthermore, the PDTCH channel is a uni-directional channel while real-time services tend to require bi-directional channels. Even for streaming traffic, which is mainly a one-way application, it seems difficult to allocate the return direction to other users, since these users would most likely generate traffic in the other direction, where a preemption of resources for “streaming” traffic in an unacceptable way.

The object of the present invention is in particular to propose another approach for supporting real-time services on a “Gb” type interface, making it possible in particular to avoid all or part of the drawbacks mentioned above, or even requiring very few adaptations by compared to existing architectures.

One of the objects of the present invention is a method for supporting real-time traffic in a mobile radiocommunication system, as defined in the claims. Another object of the present invention is radio access network equipment for mobile radiocommunication system, comprising means for implementing such a method.

Another object of the present invention is a core network equipment for a mobile radio communication system, comprising means for implementing such a method.

Another object of the present invention is a mobile station for a mobile radio system, comprising means for implementing such a method. Other objects and characteristics of the present invention will appear on reading the following description of an exemplary embodiment, made in relation to the attached drawings in which: FIG. 1 is a diagram intended to recall the general architecture of a mobile radiocommunication system, - Figure 2 is a diagram intended to recall the general architecture of a second generation system of GSM type, Figure 3 is a diagram intended to recall the general architecture of a system of third generation of UMTS type, FIG. 4 is a diagram intended to recall a general architecture initially proposed for a GERAN type system, FIGS. 5a and 5b are diagrams intended to illustrate, by comparison, the evolution proposed by the present invention for the general architecture of a GERAN type system, FIG. 6 is a diagram intended to illustrate an example of implementation of a procedure according to the invention.

The present invention suggests using existing radio channels and protocols, used for real-time services when these are relayed via the MSC. Instead of using shared channels to exchange data units or PDUs ("Packet Data unit") from / to the SGSN, the idea is to use dedicated (or "dedicated") channels channels ”). If both real-time and non-real-time services are to be supported simultaneously, existing DTM (Dual Transfer Mode) procedures can be used to control the establishment and release of the different data streams. It is briefly recalled that the DTM functionality is a functionality making it possible to simultaneously support the two types of services (in circuit mode and in packet mode), for mobile stations able to simultaneously support these two types of service, by providing for coordination by the BSS resources required for each mode. For a detailed description of this functionality, reference may also be made to the corresponding specifications published by the standardization bodies.

The development proposed according to the invention can be illustrated by comparison of FIGS. 5a and 5b. The equipment illustrated in FIGS. 5a and 5b are those already presented in relation to FIG. 2, namely BTS, BSC, MSC (or 2G-MSC), SGSN (or 2G-SGSN); in addition, the connection between an MSC and an external network of PSTN type, via an entity of type G-MSC ("Gateway-MSC") has been illustrated in FIGS. 5a and 5b; similarly the connection between an SGSN and an external network of PDN type, via an entity of type GGSN ("Gateway GPRS Support Node") has been illustrated. The interfaces "Abis" between BTS and BSC, "Gn" between SGSN and GGSN, and "Gi" between GGSN and PDN have also been illustrated. The aim being in particular to be able to support IMS type services, in FIG. 5b, PDN has been replaced by IMS.

FIG. 5a corresponds to a conventional architecture, in which the real time services relayed via an MSC are transported via dedicated channels on the radio interface.

FIG. 5b corresponds to an architecture according to the invention, in which the real time services relayed via an SGSN are transported via dedicated channels on the radio interface.

In the existing GSM architecture, two types of unit are provided to handle the two types of calls, in circuit mode and in packet mode. These two types of units may or may not be physically integrated into the same equipment.

The unit responsible for handling calls in packet mode, or PCU ("Packet Control

Unit ”) is generally provided in the BSS.

Thus, generally, there is in the BSS a unit connected to the interface “A” and which processes calls in circuit mode, and another unit connected to the interface “Gb” and which processes calls in packet mode. Circuit mode calls are transported using dedicated channels, i.e. permanently allocated for the duration of the call, while packet calls are transported using shared channels, i.e. shared with other users.

The invention proposes to support real-time services in the unit connected to the “Gb” interface through the following functions: - link relocation support “Gb” when the mobile station changes cells and when the new cell is controlled by a BSS different from the BSS controlling the old cell, and when a real-time session is in progress through the “Gb” interface, PFC (“Packet Flow Context”) procedure support to negotiate the parameters QoS with SGSN during activation / modification of PDP context,

When a PFC is created / modified for a real-time data flow, the unit connected to the “Gb” interface triggers the establishment / modification of a dedicated channel, - the real-time data units received from / to the "Gb" interface are transported on the radio interface by means of dedicated channels, when a "handover" is required, the existing procedures and mechanisms defined for the dedicated channels are used; the only difference is that the MSC is not informed; instead, the unit connected to the "Gb" interface is informed, and ensures if necessary a "Gb" link re-location. Before describing an example of implementation of the present invention, we first recall the protocols or procedures specific to packet mode systems, or to IMS type architectures, insofar as they can be useful for the description of this example.

According to the layered architecture used to describe packet mode systems, in particular of the GSM / GPRS type, a distinction is made, on the radio interface between MS and BSS: a first layer, or physical layer, - a second layer, or layer link, itself divided into several layers: in order of increasing levels, MAC (for “Medium Access Control” in English), RLC (for “Radio Link Control” in English) and LLC (for “Logical Link Control” in English ). Similarly, a distinction is made, on the “Gb” interface between BSS and SGSN: a first layer, or physical layer, a second layer, or link layer, itself divided into several layers: in order of increasing levels, “Frame Relay "(in English), BSSGP (for" BSS GPRS Protocol "in English), and LLC (for" Logical

Link Control ”.

Frames called LLC frames (or “LLC frames” in English) are formed, in the LLC layer, from data units received from a higher level, or network layer, via an adaptation layer or SNDCP (“ Subnetwork Dependent Convergence Protocol ”). In LLC frames, these data units are called LLC-PDU data units (for “LLC-Protocol Data Units”).

The LLC-PDU data units are then segmented in the RLC / MAC layer, so as to form blocks called RLC data blocks (or "RLC data blocks"). The RLC data blocks are then put into the format required for transmission over the radio interface, in the physical layer.

In addition, signaling protocols are provided, in particular for radio resource management or RR (“Radio Resource Management”), mobility management or MM (“Mobility Management”), session management or SM (“Session Management "), logical link control or LL (" Logical Link Control "), ... etc. It is also recalled that, according to the radio resource management protocol, different modes are possible for a mobile station, in packet mode: a mode known as “packet transfer mode”, in which resources are temporarily allocated, when data is actually at transmit during a communication, these resources forming a temporary virtual channel or TBF (“Temporary Block Flow”) allowing a transfer of data between mobile station and network, for a given direction of transmission, a mode called “packet idle mode” , in which no TBF is established.

In contrast, in circuit mode, the mode in which resources are allocated to a mobile station is called “dedicated mode”, these resources then being dedicated resources allocated to the mobile station for the duration of the call. In the case where both dedicated resources and resources shared are allocated to the mobile station at the same time, said mobile station is in "dual transfer mode".

When it is switched on, a mobile station is also called in standby mode, or "idle mode". In addition, according to the mobility management protocol, a procedure known as “GPRS Attachment” (or “GPRS Attach”) is defined, allowing a mobile station to switch from “idle mode” to a mode called “GPRS Attachment”. "(Or" GPRS attached "), in which it can access GPRS services. We also define the reverse procedure of "GPRS Detach". A mobile station in standby mode and not attached to GPRS communicates with the network by means of signaling exchanges on channels called CCCH ("Common Control CHannel"). A mobile station attached GPRS and in “packet idle mode” communicates with the network by means of signaling exchanges on channels called PCCCH (“Packet Common Control CHannel”) if such channels are provided in the cell considered, otherwise by CCCH channels. A mobile station attached GPRS and in “packet transfer mode” communicates with the network by means of signaling exchanges on channels called PDCH (“Packet Data Channel”).

It is recalled that the PDCH data channel includes a traffic channel or PDTCH ("Packet Data Trafic Channel"), and a signaling channel or PACCH ("Packet Associated Control CHannel").

It is also recalled that the CCCH channel itself includes a certain number of channels such as in particular a PCH (“Paging CHannel”) channel. Similarly, the PCCCH channel itself includes a certain number of channels such as in particular a PPCH (“Packet Paging CHannel”) channel.

It is also recalled that when a session must be established in a system such as GPRS, a contextual activation procedure for packet data protocol (or PDP, for "Packet Data Protocol") must be launched. The PDP context (or "PDP context") contains the information necessary for the transfer of data between MS and GGSN (routing information, QoS profile, etc.).

It is also recalled that in an IMS type architecture, signaling relating to multimedia call session control has so far been defined for UMTS type technologies. Such signaling thus typically comprises the establishment of an RRC connection between a mobile station and a RAN, followed by the establishment of a UMTS carrier to transport the signaling relating to the SIP protocol. The RRC protocol, for “Radio Resource Control” is defined in the 3GPP TS 25.331 standard. The SIP protocol ("Session Initiation Protocol") as well as the SDP protocol ("Session Description Protocol") which is linked to it have been defined by the IETF ("Internet Engineering Task Force") which is the standardization body for the Internet protocol, or IP (for “Internet Protocol”).

The main stages of such signaling are the following, denoted SI, S2, S3. For simplicity, we only consider here one of the three segments into which call session control is broken down, in this case the segment which goes from the calling UE to its S-CSCF, the other two segments being the segment which goes from the called UE to its S-CSCF, and the segment which connects the S-CSCFs from the calling UE and from the called UE. It is recalled that the entities S-CSCF (“Serving-Call Session Control Function”) and P-CSCF (“Proxy-Call Session Control Function”) are entities of the core network, in charge of controlling multimedia call sessions .

The stage SI corresponds essentially to a stage preliminary to the establishment of session.

Step SI uses a procedure known as activation of a data protocol context in packet mode, or PDP context (or “PDP Context”, for “Packet Data Protocol Context”), necessary for the transport of multimedia session control signaling. . It is recalled that a PDP context comprises a set of UMTS carrier parameters, such as in particular quality of service parameters, or QoS (for “Quality of Service”), etc.. This step will be followed later by another PDP context activation procedure, necessary for the transport of data linked to the multimedia session itself. Since these two PDP contexts relate to the same IP address, the step SI will also be called the primary PDP context activation procedure.

The step SI itself essentially comprises the following steps. In a step SU, a request for activation of a PDP context is transmitted from the UE to the RAN, with the corresponding end-to-end QoS parameters for the UMTS carrier of SIP level signaling. In a step SI 2, the 3G-SGSN commands the establishment of a radio access carrier (or RAB, or "Radio Access Bearer") so that a medium is available between UE and 3G-SGSN, meeting the quality of service constraints. When the RAN receives such a request, after a call admission check, it establishes a radio carrier (or RB, or "Radio Bearer") on the radio interface (step SI 3) and a read carrier (or " lu bearer ") on the" lu "interface. The establishment of the RAB can then be confirmed (step SI 4) and the PDP context activated (step SI 5), after negotiation with the 3G-GGSN (step S1 6, SI 7).

Step S2 essentially corresponds to the establishment of the multimedia session at the level of the SIP protocol. This step includes negotiation to determine the characteristics for the session being established. This negotiation notably includes a codec negotiation, making it possible to determine a list or set of codecs capable of being supported jointly by the two parties to the call and authorized by all the intermediate network nodes, for this session.

It will be recalled that the codecs determine, both in the mobile stations and in the radio access network (in particular in the base stations) as well as in the core network, how to perform the source coding and the channel coding necessary in particular for the transmission on the radio interface. For example, for speech coding, in a GSM type system, there are different types of codecs: full speed (or FR, for "Full Rate"), improved full speed (or EFR, for "Enhanced Full Rate") , half-speed (or HR, for "Half Rate"), or even AMR (for "Adaptive Multi-Rate coding"), the latter being particularly advantageous in that it makes it possible to optimize the quality of service (in l occurrence by selecting at each instant, according to the transmission conditions encountered, an optimal combination of a given source coding and a given channel coding). There are two types of AMR codec: the narrowband coded "Narrowband AMR" and the broadband coded "Wideband AMR". A coded type "Wideband AMR" offers an even better quality of service but requires higher radio rates. The speech case is of course only an example of the different components, or different media streams, forming a multimedia session. Step S2 essentially comprises the following steps. Once a

RB has been established for SIP signaling (by means of the previous step SI), a first task consists of the SIP client discovering its P-CSCF. Then, he will have to declare himself and register with his S-CSCF, which will call on other entities network core. Finally, during a session establishment, a request called “SIP Invite” is sent to the called party via the P-CSCF and S-CSCF entities. This message contains an SDP datagram which indicates for each media stream that the calling UE wishes to establish, a certain number of media parameters such as: media type, combination of QoS attributes, list of codecs capable of being supported. for this session, ... etc. The P-CSCF and S-CSCF entities associated with the calling party and then with the called party then perform a service check (according to network-specific criteria) on these parameters. The called party then determines among other things its own list of codecs capable of being supported for this session, then a list of codecs capable of being jointly supported by the two parties, calling and called, and then returns this last list to the appellant. The calling party then determines which media streams should be used for this session, and which codecs in this list should be used for this session. Step S3 essentially corresponds to an end of session establishment, and includes a resource allocation step, based on the media flow characteristics (in terms of QoS attributes, negotiated coding, etc.) thus determined. in step S2.

Step S3 also uses a PDP context activation procedure, also called a secondary PDP context activation procedure (to distinguish it from the primary context activation procedure used in step S1). Step S3 is similar to step S1, except that the UMTS carrier parameters to be established now correspond to the needs determined in step S2. Step S3 itself comprises steps which are similar to those of step S1, and which for this reason will not be re-described.

Step S3 thus comprises the establishment of an RAB for this secondary PDP context. When this RAB is established, the RAN performs admission control and accepts or rejects the call.

It is also recalled that, in general, in these systems, it is necessary to provide a management of the quality of service (or QoS, for "Quality of Service") so as to satisfy the needs of the users, taking into account differentiation of applications and users, and while using the available transmission resources as efficiently as possible. Generally, each service is defined by quality of service parameters or attributes (such as guaranteed bit rate, transfer delay, etc.), all of these parameters or attributes forming a profile quality of service. For GPRS, quality of service management has been improved between versions R97 and R99 of the standard.

In the R97 version of the standard, only non-real-time services can be offered to users. Thus, in the uplink direction, the mobile station can indicate QoS parameters when it requires the establishment of a TBF (for “Temporary Block Flow”) in the uplink direction, using a so-called two-phase access procedure. . In the downward direction, each LLC PDU received from the SGSN contains an information element called "QoS Profile Information Element", giving limited information on the quality of service. These parameters can be used by the BSS to effect service differentiation to some extent.

In the R99 version of the standard, a new procedure, or procedure for creating "BSS Packet Flow Context" was introduced, defined in particular in the specifications 3GPP TS 23.060 and 3GPP TS 08.18. This procedure authorizes negotiation between the SGSN and the BSS of all the QoS parameters to be offered for the transfer of any LLC-PDU relating to the PFC (“Packet Flow Context”) thus created. The SGSN can aggregate the transfer of LLC-PDUs corresponding to several given PDP contexts (or “PDP Context”, where PDP is used for “Packet Data Protocol”) in the same PFC. This is possible if the aggregated Contexts PDPs have similar quality of service constraints. The QoS parameters thus negotiated are those defined in version R99 and contain much more information than the QoS profile defined in version R97. They contain in particular all the variables necessary for the definition of a real-time service.

The PDP context (or "PDP context") created during the establishment of a data session contains the information necessary for the transfer of data between MS and GGSN (routing information, QoS profile, ... etc.) . When activating a PDP context, if the PFC functionality is implemented in the BSS and the SGSN, the latter can request QoS parameters from the BSS which can negotiate all or part of these parameters according to its load and capabilities. This means that the data associated with a PDP context and therefore with a given QoS are well identified not only in the core network CN but also in the radio access network RAN. This ensures that the QoS offered for the PDP context is negotiated between all the network nodes, and it thus becomes possible to guarantee certain quality of service attributes. It is thus possible to obtain that a guaranteed bit rate or a maximum transfer delay is offered, which makes it possible to offer real-time services.

To support real-time applications, it is necessary that the BSS is able to offer the required throughput and also to transfer the LLC PDUs received within the limits of the maximum transfer delay. For this, it is necessary that there is as little queuing as possible in the BSS (it is recalled that the queuing is specific to the transfer used in the systems in packet mode), and that the transfer interruptions (due in particular to cell re-selections, as mentioned above) are as short as possible. This requires that the BSS always know the QoS specifications for the transfer of such data, or in other words that it has a context containing associated QoS profile information.

According to the procedure for creating "BSS Packet Flow Context", as specified in particular in document 3GPP TS 23.060, the SGSN may at any time request the creation of a context called "BSS Packet Flow Context" (or PFC), in particular when activating a PDP context.

FIG. 6 is a diagram intended to illustrate an example of implementation of a method according to the invention.

It will be noted that the present invention covers both the case of a call received by the mobile station (or “MT Call”, for “Mobile Terminating Call”) as well as the case of a call sent by the mobile station (or “MO Call ", for" Mobile Originating Call ") through the packet domain (or" PS domain "). A step in these different scenarios is the establishment of a dedicated channel, on creation of a PFC. The 3GPP specifications concerning the IMS (23.228 and 24.228) define the different flows for call establishment, and the purpose is not here to recall them. In all the scenarios, an important step which more particularly constitutes one of the objects of the present invention is the step of reserving resources. In the case of MO session establishment, this occurs between the sending of the "Final SDP ”and“ Resource Reservation successful ”. In the case of MT session establishment, this occurs after the “Final SDP” message has been received from the calling party.

It is assumed that a PDP context for SIP signaling is established and that the MS is in “Packet Idle Mode”, when a resource reservation is made (if a TBF is in progress, then the first establishment of TBF does not will not be performed).

The following steps can be implemented:

(1) The MS triggers a secondary PDP context activation for the media stream, whose QoS parameters have been negotiated at the SIP level. For this, the

MS requires uplink TBF (or UL TBF, for "Uplink TBF") on shared channels.

(2) When the SGSN receives the message “ACTIVATE PDP CONTEXT REQUEST from the MS, it creates the PDP context in the SGSN and then sends a CREATE BSS PFC message on the Gb interface, in order to ask the BSS to reserve the necessary radio resources for the real-time media stream.

(3) The required QoS indicates real-time characteristics. It is proposed here to authorize the BSS to allocate dedicated resources. Two methods or procedures are proposed in the case where the BSS can allocate such resources in correspondence with the required QoS: re-use as much as possible the existing techniques by sending a paging to the MS, or introduce a new allocation message . It can be noted that at this stage the MS is necessarily in the GMM READY state since an LLC PDU in the uplink direction has just been sent, containing the message ACTIVATE PDP CONTEXT REQUEST. (3a) In a first procedure, the BSS generates a "paging" to the MS.

In the current state of the standard for A / Gb mode, an MS can receive a “CS paging” (or “paging” for circuit mode services) only if this “CS paging” is received from the MSC. It is proposed here that the BSS generates a “paging” for real-time services after having received a request from the SGSN. Depending on the radio state of the MS, the "paging" message can be sent either on common control channels or on the PACCH of a TBF in progress. This would be similar to "CS paging", with the exception that an indication would be present to indicate that this "paging" comes from the PS ("Packet Switched") or packet mode domain. If one or more TBF were in course, the MS will return to the common control channels and initiate a random access procedure by requesting dedicated resources (another option would be to improve DTM (Dual Transfer Mode) procedures in a way authorize the MS to initiate dedicated access through the PACCH of a TBF in progress). The BSS will then allocate dedicated resources and the MS will establish the Layer 2 signaling link.

It is also proposed to ask the mobile station MS to send a GPRS INFORMATION message containing the TLLI identifier ("Temporary Logical Link Identifier") specific to the mobile station MS. This message can also contain an empty LLC frame superimposed (“piggybacked” in English) on the SABM message. The TLLI will be returned to the BSS, so that the BSS can associate the newly established connection with the request received in the CREATE BSS PFC message. In the case where the allocated resources do not correspond to the required QoS, an intracellular “handover” can be carried out to allocate resources in correspondence with the request received from the SGSN (or in correspondence with the QoS negotiated with the SGSN) if such resources are available. The GPRS INFORMATION message can be sent on the dedicated channel DCCH (“Dedicated Control Channel”) once established. Note that any other message containing the MS TLLI can be used.

(3b) In a second procedure, dedicated resources are allocated directly to the MS: a new message could be introduced, avoiding the need to have to send a "paging" to the MS. The BSS would then directly allocate the dedicated resources, through a new message sent on the common control channels (MS in “Packet Idle Mode”) or on the PACCH of a TBF in horns (MS in “Packet Transfer mode” Fashion "). The MS will then activate the new resources (possibly by switching to “RR Dual Transfer Mode” if one or more TBFs were in progress) and will establish the layer 2 signaling link. As in the first procedure, the MS will send a message GPRS INFORMATION containing the TLLI, which will be returned to the BSS. In this case, the allocated resources should correspond to the required QoS. (4) The BSS then sends an acknowledgment to the SGSN for the creation of the PFC. Note that if the BSS cannot allocate resources to achieve the required QoS, it can first try to negotiate the parameters QoS, and if the negotiation succeeds, it can then carry out the establishment of dedicated channels.

(5) Activation of the PDP context is then completed (through the establishment of a TBF, or by using the GPRS INFORMATION message, or by using an existing TBF if it is still in progress),

(6) Call establishment can then be completed at the SIP level.

When the session has started, the real-time PDUs are routed as follows: in the network direction to MS: GGSN -> SGSN (Interface "Gn"), SGSN -> BSC (interface "Gb"), BSC- BTS (Interface Abis), BTS - »MS

(Radio interface) in the MS to network direction: MS -> BTS (Radio interface), BTS -> BSC

(Abis interface), BSC - SGSN (Gb interface), SGSN ^• »GGSN

(“Gn” interface) On the “Gb” and “Gn” interfaces the PDUs are routed like packets. On the Abis and radio interfaces, the PDUs are transported on dedicated channels.

During the real-time flow, the radio measurements reported are sent from the MS to the BSS on the existing SACCH. On the basis of these deferred radio measurements, the BSS can carry out “handovers” using existing mechanisms. In FIG. 6: step 61 indicates that the establishment of a call is in progress for a real-time media stream, the “Final SDP” has just been sent (in the case MO) or received (in the case MT), - step 62 indicates that a secondary PDP context is created in the

SGSN, step 63 indicates that the BSS has received a “PFC Creation Request” for a real time flow, it establishes dedicated resources, step 64 indicates that the MS activates the dedicated resources allocated, - step 65 indicates that multi-frame operation is now established, the contention is resolved, and the BSS knows the TLLI of the new connection. A "handover" is carried out if necessary, step 66 indicates that the SIP call establishment can then occur, the option corresponding to the first procedure indicated above has been noted 67 - the option corresponding to the second procedure indicated above has been noted 68. The different messages noted in Figure 6: (P) RACH, PACKET UPUNK ASSIGNMENT, ACTIVATE PDP CONTEXT REQUEST (secondary PDP context), CREATE BSS PFC, CS PAGING (from the PS domain), IMMEDIATE ASSIGNMENT, SABM + GPRS INFORMATION, UA + GPRS INFORMATION, CREATE BSS PFC ACK, ACTIVATE PDP CONTEXT ACCEPT, have either been recalled or defined previously. Optionally, for more information on existing messages or procedures, reference may be made to the corresponding specifications for these systems).

It will be noted that the example thus described constitutes only one of the possible examples of implementation of the invention. It will be understood that it is not possible to describe here all the possible examples of implementation, and that the present invention is of course of general application, and is not limited to this particular example.

One of the advantages of the invention is that the existing procedures or protocols are re-used. In particular, there is no need to introduce a new channel combination, nor a TBF handover. The impacts on a mobile station according to the R99 version of the standard supporting the DTM (Dual Transfer Mode) mode are reduced to a minimum (the PDP context for which a dedicated channel is allocated must be indicated to the mobile station). There is no need to define a new protocol layer on top of the RLC / MAC layer since the RR layer on top of

LAPDm can be reused. All signaling can be done through the existing SACCH and FACCH channels. This does not prevent the improvement of procedures

Existing DTMs to support simultaneous handovers of real-time traffic transported in dedicated channels and non-real-time traffic transported in shared channels. In particular, the invention makes it possible to introduce support for IMS services in the "A / Gb" mode of the GERAN network at minimum cost.

Claims

1. Method for supporting real-time traffic in a mobile radio communication system comprising a radio access network and a core network, method in which real-time traffic supported in packet mode in the core network is supported in the network radio access through allocation of dedicated channels.

2. Method according to claim 1, in which said allocation of dedicated channels is carried out when creating a packet flow context (PFC).

3. The method of claim 2, wherein said packet flow context is created in the radio access network.

4. The method of claim 3, wherein said packet flow context contains QoS parameters to be offered by the radio access network and negotiated with the core network.

5. Method according to one of claims 1 to 4, wherein said real-time traffic corresponds to at least one media stream from a multimedia session.

6. Method according to one of claims 1 to 5, wherein said allocation of dedicated channels uses an allocation procedure comprising a "paging" followed by access to the network.

7. Method according to one of claims 1 to 5, wherein said allocation of dedicated channels uses a direct allocation procedure.

8. Method according to one of claims 1 to 7, in which: a mobile station to which dedicated channels have thus been allocated transmits information relating to its identity to the network, on the basis of this information, the network associates a context packet flow to this mobile station, and, if necessary, a re-allocation of dedicated channels is carried out in order to satisfy the quality of service required for this mobile station.

9. Radio access network equipment for a mobile radiocommunication system, comprising means for implementing a method according to one of claims 1 to 8.

10. Core network equipment for a mobile radiocommunication system, comprising means for implementing a method according to one of claims 1 to 8.

1 1. Mobile station for mobile radio communication system, comprising means for implementing a method according to one of claims 1 to 8.