slide 1

Back to the List of the Granted Patents                                                                        Click here to download KE000441 PDF

(2l)Application Number:KElP/ 2008/ 000736   
           
(22) Filing Date: 27/10/2006       
           
(30) Priority data: 05023869.0    02/1112005    EP and 111335,053    18/01/2006 us

(86)  PCT data    PCT /IB06/003026    27/10/2006 wo 2007/052114    10/05/2007

(73) Owner: NOKIA CORPORATION ofKeilalahdentie 4, FI-02150 Espoo, Finland

(72) Inventor: LAPPALAINEN, Kristian of Aittatie  2 C  13, FI-90240 Oulu, Finland

(74) Agent/address for correspondence: Hamilton  Harrison & Mathews, ICEA Building, Kenyatta Avenue, P.O. Box 30333-00100, Nairobi           
                       
(54) Title: TRAFFIC GENERATION DURING INACTIVE USER PLANE

(57) Abstract: The present invention relates to a method, transmitting device (10) and system for providing user plane traffic during a state of inactive user plane of a connection to an access network. A sequence of successive packet headers, adapted to continue a header sequence transmitted until the start of the state of inactive user plane is generated, and respective dummy portions are added to the esquence of successive packet headers. The generated stream of data packets is then transmitted from the transmitting device (10) via the unlicensed mobile access network during the state of inactive user plane so as to obtain a continuous stream of user data irrespective of the state of inactive user plane. Thereby, user plane traffic can also be provided during states of inactive user plane of the transmitting device (1 0), e.g. holding states, call setup states, and real-time traffic requirements can be met.

Traffic Generation during Inactive User Plane

FIELD OF THE INVENTION

5    The present invention relates to a method, transmitting device, terminal device, network controller device and system for providing user plane traffic through an access network, such as an unlicensed mobile access (UMA) network.

BACKGROUND OF THE INVENTION

UMA technology enables alternative access to cellular mobile services, e.g. GSM 10 (Global System for Mobile communication), WCDMA (Wideband Code Division

Multiple Access) or GPRS (General Packet Radio Services) over an unlicensed spectrum, including WLAN (Wireless Local Area Network), Bluetooth™ and WiFi™. The UMA technology enables seamless delivery of mobile voice and data services over unlicensed wireless networks. The same mobile identity is provided on cellular

15 radio access networks and unlicensed wireless networks, so that seamless transi-tions (e.g. roaming and handover) between these networks is possible.

In particular, UMA provides an extension of GSM/GPRS mobile services into the customer'spremises that is achieved by tunneling certain GSM/GPRS protocols

20    between the customer'spremises and the core network over a broadband IP (Internet Protocol) network, and relaying them through an unlicensed radio link in-side the customer'spremises. UMA is a complement to traditional GSM/GPRS ra-dio coverage, used to enhance customer premises coverage, increase network capacity and potentially lower costs. UMA constitutes a part of the radio access

25    network and is introduced by adding a UMA Network Controller (UNC) as a link between the WLAN and the GSM core network using standard A and Gb inter-faces. Hence, from the GSM core network'sperspective, the UNC is perceived as

just another Base Station Controller (BSC). The UNC functionality could also be

introduced into existing BSC infrastructure, thus offloading the core network from

30    signaling and multiple resource handling related to users shifting between WLAN and GERAN (GSM/EDGE Radio Access Network) in the same area.

In UMA it is possible to put a call on hold, like in normal circuit-switched (CS) call. Real-time traffic, such as audio or video, of the CS domain user plane is received

at the UNC via the Up interface and conforms to the RTP (Real Time Protocol) fram-ing format defined in the IETF (Internet Engineering Task Force) specifications

RFC 3267 and RFC 3551. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast net-

5    work services. The data transport is augmented by the Real Time Control Protocol (RTCP) to allow monitoring of data delivery in a manner scalable to large multicast networks and to provide minimal control and identification functionality. RTP and

RTCP are designed to be independent of the underlying transport and network lay-

ers. An RTP packet consists of a fixed RTP header, a possibly empty list of con-

10    tributing sources, and payload data. The RTP payload comprises the data trans-ported by RTP in the RTP packet, for example, audio samples or compressed video data. The source of a stream of RTP packets is identified by a 32-bit numeric synchronization source (SSRC) identifier carried in the RTP header so as not to be

dependent upon the network address. Additionally, a source of the stream of RTP

15    packets that has contributed to the combined stream produced by an RTP mixer can be identified in a contributing source (CSRC) list. Such a list can be used, for example, in audio conferencing to identify all participants whose speech was com-bined to produce an outgoing packet, allowing the receiver to indicate the current talker, even though all audio packets contain the same SSRC identifier.

20    Additionally, the RTP header includes a payload type (PT) field of 7 bits, which identifies the format of the RTP payload and determines its interpretation by the application, a sequence number (SN) field of 16 bits, which is incremented by one for each RTP data packet sent and which may be used by the receiver to detect

packet loss and to restore the original packet sequence, and a time stamp (TS) of

25    32 bits, which reflects the sampling istant of the first octet in the RTP packet. The sampling instant can be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations.

However, UMA Protocols (Stage 3) R1.0.4 require that a mobile terminal or user

equipment (UE) sends RTP packets at least every 480ms. During a holding state

30    (call-on-hold) of the UE the audio encoding is stopped. Thus, there is no input to the RTP protocol to send to the network. Also, the UMA protocols do not describe at all how the call-on-hold situation should be handled in RTP packet point of view. In this regard, the UMA Protocols require that all RTP data traffic during one UMA call (including a call-on-hold situations) relates to the same RTP stream. This
 

35    means RTP headers'SSRC and PT fields are identical, the TS field is incremented

according to the payload decoding (will not be incremented if there is no payload) and the SN field is incremented in each packet.


SUMMARY OF THE INVENTION

5    It is therefore an object of the present invention to provide a method, transmitting device and system for enabling a holding state of a transmitting device connected via an unlicensed mobile access network.

This object is achieved by a method of providing user plane traffic during a state of

inactive user plane of a connection to an access network, said method comprising

1 0   the steps of:

•    generating a sequence of successive packet headers, adapted to continue a header sequence transmitted until the start of said state of inactive user plane;

•    adding to said generated header sequences respective dummy portions;

•    transmitting said stream of data packets via said access network during said 15 state of inactive user plane so as to obtain a stream of user data irrespective of

said state of inactive user plane.

Furthermore, the above object is achieved by a transmitting device for providing user plane traffic during a state of inactive user plane of a connection to an access network, said transmitting device comprising:

20    • header generating means for generating a sequence of successive packet headers, adapted to continue the header sequence transmitted until the start of said state of inactive user plane;

•    dummy portion generating means for generating dummy portions of data pack-ets; and

25    • packet assembling means for adding said generated dummy portions to said generated sequence of successive packet headers, so as to obtain a stream of data packets; and

transmitting means for transmitting said stream of data packets during said state of inactive user plane so as to obtain a continuous stream of user data ir-respective of said state of inactive user plane.

Accordingly, the call-on-hold problem, or any other problem associated with a state

5    of an inactive user plane (where no user traffic is available) can be solved by trans-mitting a stream of data packets with packet headers adapted to seamlessly match with the header sequence transmitted until the start of the state of inactive user plane, e.g. holding state. The data packets are generated by adding respective dummy portions to the packet headers. The generated stream of data packets pro-

10    vides continuous user plane traffic during the state of inactive user plane, so that the RTP requirements can be met.

According to a first aspect of the present invention, the dummy portions are gener-ated with an information indicating that no data is carried in a payload portion of the data packets. As a specific example, the information could be a NO_DATA field of

15    an adaptive multi-rate (AMR) speech coder.

According to a second aspect of the present invention, the dummy portions could be generated to include no payload. Then, a time stamp information of the gener-ated successive packet headers could be set or selected to be identical to a time

stamp information of the last packet which included payload and which was trans-

20    mitted before the start of the holding state.

According to a third aspect of the present invention, the dummy portions could be generated to comprise a silence descriptor information. Here, a transmission inter-val between packets of the stream of data packets could be set or selected during the holding state based on the length of a comfort noise defined by the silence de-

25    scriptor information.

Finally, according to fourth aspect of the present invention, the dummy portion could be copied from packets received at the transmitting device during the state of inactive user plane, so that received packets are looped back with modified head-ers.

30    In all above first to fourth aspects, packet transmission during the state of inactive user plane may be performed at a predetermined interval. Furthermore, a se-quence number of the generated successive packet headers may be incremented

incremented with each successive packet header. The stream of data packets may be generated in accordance with a real time protocol.

The transmission device may be comprised in a terminal device, e.g. a mobile phone or user equipment, or in a network controller device.

5    The state of inactive user plane may be at least one of a holding state and a mute state.

Further advantageous modifications are defined in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described based on a preferred embodiment with

10    reference to the accompanying drawings in which:

Fig. 1 shows a schematic diagram of an UMA network architecture in which the preferred embodiments can be implemented; and

Fig. 2 shows a schematic block diagram of a transmitting device according to the preferred embodiments.

15    DESCRIPTION OF THE PREFERRED EMBODIMENT

In the following, the preferred embodiment will be described in connection with a terminal device connected via an UMA network to a GSM- or GPRS-based net-work.

Fig. 1 shows a schematic UMA network architecture, wherein the UMA network

20    consists of one or more access points (not shown) of a WLAN 20 or any other IP-based network, through which a UE or mobile station (MS) 10 can be connected via an UMA tunnel 50 to a media gateway (MG) functionality 32 of a UMA network controller (UNC) 30. From there, the data traffic is routed to a mobile switching cen-ter (MSC) of the GSM/GPRS network 40.

25    The access points of the WLAN 20 provide a radio link to the MS 10 using an unli-censed spectrum. The UNC 30 appears to the core network, i.e. GSM/GPRS net-work 40, as a GERAN base station subsystem (BSS). It includes a security gate-

gateway that terminates the secure remote access tunnel 50 from the MS 10, providing mutual authentication, encryption and data integrity for signaling, voice and data traffic. The WLAN 20 provides connectivity between the access point and the UNC 30. The UMA tunnel 50 functions as an IP transport connection which

5    extends all the way from the UNC 30 to the MS 10, through the access point. In this archtecture, the principle elements of transaction control (e.g., call processing) and user services are provided by network elements of the GSM/GPRS core network 40, namely the MSC 42 or corresponding GPRS network elements, such as a Serving GPRS Support Node (SGSN) or a Gateway GPRS Support Node

10    (GGSN).

In the following, four alternative solutions for providing user plane traffic during a holding state (call-on-hold) of the MS 10 are described based on respective first to

fourth embodiments. The solutions are based on the concept of generating a virtual

user plane traffic by adding respective dummy or faked packet portions to a se-

15    que nee of matched packet headers which are configured to continue a real packet stream generated before and until the start of the call-on-hold state, so that a seamless or continuous stream of RTP packets is obtained even throughout the duration of the call-on-hold state of the MS 10.

According to the first embodiment,  the MS 10 is configured to send at some inter-

20    val (e.g. 480ms) during the call-on-hold state, RTP packets that contain an AMR NO_DATA field or another information indicating that the packet does not include any speech or other real-time data as the payload. In order to be compliant, this means that the RTP SN has to increase accordingly.

25    According to the second embodiment, the MS 10 is configured to send during the call-on-hold state, RTP packets that contain no payload and which TS fields are identical to those which were used by the last RTP packet containing real payload during the call. The value of the SN field should increment accordingly in order to allow improved function of third party RTP traffic monitors. Otherwise the RTP traf-

30    fie monitors would consider the RTP packets as duplicates. The receiver of such an RTP packet will ignore it for several reason. First, the RTP packet contains no pay-load, and second, the value of the TS field is a duplicate from the last received cor-rect RTP packet.

35    The second embodiment provides the advantage that the frequency of the RTP packets can be optimized to an interval which fulfills best the 480ms rule of the

UMA specification. Moreover, the overall packet size is the smallest. Due to the possibility of optimizing the time interval between successive packets to be as long as possible, power savings can be maximized. The MS 10 can implement power saving by stopping its encoder function during the call-on-hold state, so that no real

5    source for is provided for silence descriptor (SID) frames.

According to the third embodiment, the MS 10 is configured to send during the call-on-hold state, RTP packets that contain an AMR SID as their payload. In order to

be compliant this means that the RTP SN and TS have to be increased accord-

10    ingly.

According to the fourth embodiment, the MS 1 0 is configured to "loop back" the received RTP packets during the call-on-hold state. Here, the MS 10 needs to
modify the RTP headers from the looped back RTP packets so that they belong to

15    the same RTP stream transmitted until the start of the call-on-hold state. This solu-tion requires that the UNC 30 sends the packets at least at the required 480ms in-terval.

Fig. 2 shows a schematic block diagram of a transmitting device, which may be comprised in or which may correspond to the MS 10 with enhanced call-on-hold

20    functionality according to the above first to fourth preferred embodiments.

It is noted that Fig. 2 only shows those functionalities which are required for ex-plaining the preferred embodiments. Other functional blocks have been omitted to keep the description short and simple.

According to Fig. 2, the MS 10 comprises a transceiver unit (TRX.} 17 for transmit-

25    ting and receiving data packets via an air interface to an access point of the WLAN

50.    The transmitted RTP packets are generated at a baseband processing circuit 18 including a speech codec function or unit 181, such as an AMR codec, and an RTP codec function or unit 182, which receives coded user data from the speech

codec unit 181 and generates RTP packets comprising the coded user data in their

30    payload portion. Input and/or output of RTP payload data, e.g. speech, voice or other real-time data, is achieved by means of a user interface (UI) 19 which may comprise a display, speaker(s), a microphone etc.

Furthermore, during a call-on-hold state, an additional packet assembling function or unit 12 is activated, which generates user plane traffic by combining or adding a
 

sequence of packet headers H generated at a header generation function or unit 14 and respective dummy portions P generated at a dummy portion generating function or unit 16. The (virtual) RTP packets obtained at the output of the packet assembling unit 12 during the call-on-hold state are supplied to the baseband

5    processing unit 18 where they are processed to obtain a continuous user plane traf-fic supplied to the TRX 17 for uplink transmission through the UMA tunnel 50. Thereby, user plane traffic can be provided even if the encoder functionality of the codec 181 is deactivated during the call-on-hold state.

In all first to fourth embodiments, the header generating unit 14 serves to generate

10    a sequence of RTP headers, which continues the header sequence of (real) RTP packets transmitted until the start of the call-on-hold state. To achieve this, at least the RTP SN field can be incremented with each successive packet, starting from the last packet with real payload transmitted before the start of the call-on-hold state. In general, it is sufficient to generate a header sequence which will be inter-

15    preted by the UMA network as RTP data traffic which relates to the same RTP stream transmitted before the start of the call-on-hold state. The required informa-tion about the last RTP packet (with real payload) transmitted before the start of the call-on-hold state can be supplied to the header generating unit 14 by the base-band processing unit 18.

20    The dummy portion generating unit 16 has been drawn with dotted lines in Fig. 2, since this is an optional unit at least for the second preferred embodiment where no payload is added to the sequence of packet headers.

In the first preferred embodiment, The dummy portion generating unit 16 is adapted

to supply an AMR NO_DATA field to the packet assembling unit 12, while the

25    header generating unit 14 generates a header sequence with an RTP SN incre-mented with every following header.

In the second preferred embodiment, the dummy portion generating unit may be dispensed with, while the header generating unit 14 or the packet assembling unit 12 incorporate the required dummy portion or dummy information (e.g. PT field

30    etc.) to indicate that the RTP packet contains no payload. In general the term "dummy portion" is to be understood throughout this specification in a sense that it does not relate to real traffic generated by the user or based on the user behavior, but merely serves to generate user traffic during the call-on-hold state.

In the third preferred embodiment, the dummy portion generating unit 16 is adapted

to supply AMR SID field{s) to the packet assembling unit 12, while the header gen-

erating unit 14 generates a header sequence with RTP SN and TS fields incre-

mented with every following header.

5    In the fourth preferred embodiment, the dummy portion generating unit 16 receives from the baseband processing unit 18 copies of the RTP packets received during the call-on-hold state and forwards a portion of these copied RTP packets without header to the packet assembling unit 12, where the new headers generated by the

header generating unit 14 are added, to obtain new user plane traffic to be looped

10    back to the UMA network. Again, the header generating unit 14 may generate a header sequence with RTP SN and TS fields incremented with every following header.

The sending of RTP packets with dummy portion could be used also in the begin-

ning of a call, before the actual call is active. This would mean that RTP packet

15    sending may be triggered by an uplink user plane RTP stream generated at the MA 10 or by an URR Active Channel Complete Message received at the MS 10.The actual call starts after receipt of a connect message (e.g. URR DL DIRECT TRANSFER). There can be a big time gap between the above trigger event and

the start of the call, due to various facts (e.g. signals can be lost, other end needs

20    to answer the call, etc.).

The transmitting device of Fig. 2 may as well be provided in a network controller device, such as the UNC 30, where continuous transmission to the MS 10 may be required to enable quality measurements in both uplink and downlink direction in states where no user plane traffic is available.

25    It is pointed out that the present invention is not restricted to UMA networks or other networks using unlicensed frequencies. The solutions explained in connec-tion with the above first to fourth embodiments may as well be implemented in a Generic Access Network (GAN) environment involving a General Access Network

Controller (GANC), as defined in the 3GPP specification TS 44.318 V6.2.0, Ge-

30    neric Access (GA) to the A!Gb interface, Mobile GA interface layer 3 specification.

It is thus not limited to unlicensed access or even mobile access. Here, continuous transmission of RTP packets between a MS and the GANC is essential to enable quality measurements in downlink and uplink. If there is no speech sample or other

user plane traffic in the RTP packet, i.e., audio path is off or silent, The MS and the GANG can send empty RTP packets with the proposed dummy portion. The GANG may configure itself for transmission of RTP packets to the MS to the indicated UDP port and RTCP packets to the MS, if the information element (IE) 'RTCPUDP

5    Port'is included to the packet header by the MS, and may transmit a GA-CSR ACTIVATE CHANNEL COMPLETE message to the MS.

To enable downlink quality measurements in the MS, the GANG may send at least

one RTP packet each predefined period, e.g., 480 ms. If there is no user audio

10    (e.g. Call Setup phase or Call Hold) the GANG shall generate RTP idle packets comprising a dummy portion, as explained in the above first to fourth embodiments.

The RTP channel is available for use by upper layers. To enable uplink quality

measurements in the GANG, the MS 10 can send at least one RTP packet each

predefined period, e.g., 480 ms. If there is no user audio (e.g. Call Setup phase or

15    Call Hold) the MS generates RTP idle packets comprising a dummy portion, as ex-plained in the above first to fourth embodiments.

The RTP idle packets belongs to the same RTP stream as the audio packets, i.e. SSRC/PT match. In RTP idle packets, the SN is incremented, and in case the RTP

idle packet has no payload, the TS will not be incremented. In case the RTP idle

20    packet payload is has e.g. NO_DATA or SID frame(s) then TS shall be incre-mented according to the IETF specification RFC 3267.

Without definition of the RTP idle packets, any kind of RTP packet would be ac-cepted, which would cause interoperability errors, e.g., in the call setup phase or call hold phase, when audio path is off.

25    A further example of a state of inactive user plane is a mute state, in which the user may have simply muted the microphone of his terminal device, e.g. mobile phone. In this case, the user still hears the conversation but there is no user traffic to send.

In summary, a method, terminal device and system have been described for pro-

viding user plane traffic during a holding state of the terminal device which is con-

30    nected via an unlicensed mobile access network. A sequence of successive packet headers, adapted to continue a header sequence transmitted until the start of the holding state is generated, and respective dummy portions are added to the se-quence of successive packet headers to obtain a stream of data packets. The gen-
generated stream of data packets is then transmitted from the terminal device via the unlicensed mobile access network during the holding state. Thereby, user plane traffic can also be provided during the holding state of the terminal device and real-time traffic requirements can be met. In general, dummy packets are sent

5    periodically for measurement purposes in the access network.

The above described functions or units 12, 14 and 16 of the terminal device 10 as shown in Fig. 2 may be implemented as software routines which are configured to run a computer device or processor device provided in the terminal device 10. As

an alternative, these units or function as indicated by the blocks of Fig. 2 may be

10    implemented as discrete hardware circuits.

It is to be noted that the present invention is not restricted to the above preferred

embodiments but can be implemented in any other network which uses user plane traffic, such as Voice over IP (VoiP) based access networks which do not allow (long) breaks in the user traffic stream. The present invention is thus applicable to

15    any packet transmission which requires continuous user plane traffic even during states of inactive user plane. The preferred embodiments may thus vary within the scope of the attached claims.

Claims

1.    A method of providing user plane traffic during a state of inactive user plane of a connection to an access network, said method comprising the steps of:

a)    generating a sequence of successive packet headers, adapted to con-

5 tinue a header sequence transmitted until the start of said state of in-active user plane;


b)    adding to said generated header sequences respective dummy por-tions;

c)    transmitting said stream of data packets via said access network dur-

10 ing said state of inactive user plane so as to obtain a continuous stream of user data irrespective of said state of inactive user plane.

2.    A method according to claim 1, further comprising the step of selecting said dummy portions to comprise information indicating that no data is carried in a payload portion of said data packets.

15    3. A method according to claim 2, wherein said information is a NO_DATA field of an adaptive multi-rate speech coder.

4.    A method according to claim 1, further comprising the step of selecting said dummy portions to include no payload.

5.    A method according to claim 4, further comprising the step of selecting a time

20    stamp information of said generated successive packet headers to be identi-cal to a time stamp information of the last packet including payload and transmitted before the start of said state of inactive user plane.

6.    A method according to claim 1, further comprising the step of selecting said dummy portion to comprise a silence descriptor information.

25    7. A method according to claim 6, further comprising the step of selecting a transmission interval between packets of said stream of data packets during said state of inactive user plane based on the length of a comfort noise de-fined by said silence descriptor information.

8.    A method according to claim 1, further comprising the step of copying said dummy portion from packets received during said state of inactive user plane, so that received packets are looped back with modified headers.

9.    A method according to any one of the preceding claims, wherein said trans-

5    mitting step is configured to transmit data packets of said stream of data packets at a predetermined interval.

10.    A method according to any one of the preceding claims, further comprising the step of incrementing a sequence number of said generated successive packet headers with each successive packet header.

10    11. A method according to any one of the preceding claims, wherein said stream of data packets is generated in accordance with a real time protocol.

12.    A method according to any one of the preceding claims, wherein said state of inactive user plane is at least one of a holding state, a call setup state, and a mute state.

15    13. A computer program product comprising code means for producing the steps of method claim 1 when run on a computer device.

14.    A transmission device for providing user plane traffic during a state of inactive user plane of a connection to an access network, said transmission device (10, 30) comprising:

20    a) header generating means (14) for generating a sequence of succes-sive packet headers, adapted to continue the header sequence trans-mitted until the start of said state of inactive user plane;

b)    dummy portion generating means (16) for generating dummy portions of data packets; and

25    c) packet assembling means (12) for adding said generated dummy por-tions to said generated sequence of successive packet headers, so as to obtain a stream of data packets; and

d)    transmitting means (17) for transmitting said stream of data packets during said state of inactive user plane so as to obtain a continuous stream of user data irrespective of said state of inactive user plane.

15.    A transmitting device according to claim 14, wherein said dummy portion gen-5        erating means (16) are configured to generate said dummy portions with an information indicating that no data is carried in a payload portion of said data
packets.

16.    A transmitting device according to claim 15, wherein said dummy portion gen-erating means (16) are configured to generate said dummy portions with a
10    NO_DATA field of an adaptive multi-rate speech coder.

17.    A transmitting device according to claim 14, wherein said dummy portion generating means (16) are configured to generate said dummy portions with-out any payload.

18.    A transmitting device according to claim 17, wherein said header generating

15    means (14) are configured to select a time stamp information of said gener-ated successive packet headers so as to be identical to a time stamp infor-mation of the last packet including payload and transmitted before the start of said state of inactive user plane.

19.    A transmitting device according to claim 13, wherein said dummy portion 20 generating means (16) are configured to generate said dummy portion with a
silence descriptor information.

20.    A transmitting device according to claim 19, wherein said transmitting means

(17)    are configured to set a transmission interval between packets of said stream of data packets during said state of inactive user plane ased on the

25    length of a comfort noise defined by said silence descriptor information.

21.    A transmitting device according to claim 14, wherein said dummy portion generating means (16) are configured to copy said dummy portion from packets received at said transmitting device (1 0) during said state of inactive user plane, so that received packets are looped back with modified headers.

22.    A transmitting device according to any one of claims 14 to 21, wherein said transmitting means (17) are configured to transmit data packets of said stream of data packets at a predetermined interval.

23.    A transmitting device according to any one of claims 14 to 22, wherein said

5    header generating means (14) are configured to increment a sequence num-ber of said generated successive packet headers with each successive packet header.

24.    A transmitting device according to any one of claims 14 to 23, wherein said packet assembling means (12) are configured to generate said stream of

10    data packets in accordance with a real time protocol.

25.    A transmitting device according to any one of claims 14 to 24, wherein said state of inactive user plane is at least one of a holding state, a call setup state, and a mute state.

26.    A system for providing communication via an access network, said system

15    comprising a terminal device (1 0) and a network controller device (30) to which said terminal device (10) is connected, at least one of said terminal de-vice (10) and network controller device (30) comprising a transmitting device as claimed in any one of claims 14 to 25.

27.    A terminal device for providing communication via an access network, said 20 terminal device comprising a transmitting device as claimed in any one of
claims 14 to 25.

28.    A network controller device for providing communication via an access net-

work,  said  network controller device comprising  a transmitting  device as

claimed    in    any    one    of    claims    14    to    25.

Abstract

The present invention relates to a method, transmitting device (10) and system for providing user plane traffic during a state of inactive user plane of a connection to an access network. A sequence of successive packet headers, adapted to continue

5    a header sequence transmitted until the start of the state of inactive user plane is generated, and respective dummy portions are added to the sequence of succes-sive packet headers. The generated stream of data packets is then transmitted from the transmitting device (10) via the unlicensed mobile access network during

the state of inactive user plane so as to obtain a continuous stream of user data

10    irrespective of the state of inactive user plane. Thereby, user plane traffic can also be provided during states of inactive user plane of the transmitting device (1 0), e.g. holding states, call setup states or mute states, and real-time traffic requirements can be met.

Newsletter

Join our newsletter for CIPIT news through subscriptions!

SEND

Social Media

    

Contact Us

TEL : (254) 703 034 612