STATE OF THE ART In the society of today it is getting more and more important for a user to be able to access services of different kinds in a manner which is as simple and easy as possible. Examples of such services are speech, conversational services, data communication services, video services and, in general, any media service.

Access to the increasing numbers of services, from a home or from an office, can be provided using generally different available access technologies such as telephony for example via PSTN or via mobile communications networks, television channels for example over cable and satellite, Internet which can be provided via modem connection over PSTN, broadband or via Ethernet cable connection. For wireless user stations there are different possibilities to access services. With the introduction of 3GPP (Third Generation Partnership Project), UMTS (Universal Mobile Telephony System), GPRS (GSM Global Packet Radio Service), a mobile user gets a wide coverage as far as different alternatives are concerned, e. g. real time services, but the data rates are quite slow.

Wireless access networks, e. g. a WLAN (Wireless Local Area Network) could be said to constitute an excellent complement to

for example UMTS. WLAN offers very high data transfer rates, but coverage is unfortunately limited to public hotspot areas, particularly (public) indoor hotspots. It would e. g. be attractive for a user to have access opportunity through these both technologies or rather a combination of both. WLAN is primarily used for high-speed data transmission in Local Area Networks. Any one with a WLAN capable device, any device equipped with a wireless LAN card, can access the Internet. The WLAN is optimized for data services, but not for real time services such as voice. Today it is also not possible to have bandwidth on demand for different media services (voice, data and video) on the same access links controlled by one and the same node and independently of transport layer technology, which is a drawback.

Each media type generally requires its own network and its own access network with network specific switches and specific access termination equipment.

It would also be attractive for a user to be able to use e. g.

Bluetooth for access of broadband services, since Bluetooth uses a cheap, short range unlicensed frequency.

So far there is no straightforward way to use e. g. Bluetooth or WLAN for accessing for example an UMTS network since there are several problems associated therewith. Mobile @ Home suggests a solution for the provisioning of 2G services (Voice and GPRS), but does not provide a solution for provisioning of 3G services at home (3GPP; Third Generation Partnership Project). This is a problem since the user would clearly appreciate having one subscription instead of two (one for 2G services and one for 3G services) and still be able to take advantage of low, fixed tariffs from home. US A/2004/0068571 shows a method for distributing service functions from an UMTS network to terminal devices in a wireless local area network by reusing UTRAN

protocols and radio resource control over the local area network.

It requires the introduction of an additional node, an access network device belonging to a first access network, which is a disadvantage. So far no satisfactory solution has been found as to the provisioning of an end user station with access to different kinds of services, i. e. services of different types, different bandwidths, different bit rates, different QoS etc. in a simple and straightforward manner. There is also no solution to the provisioning of dynamic access bearer handling/dynamic bandwidth allocation of various services on one connection link.

The user still generally has to rely on different access technologies/access networks to access different services, which is most disadvantageous and complicated, and expensive.

SUMMARY OF THE INVENTION What is needed is therefore an arrangement through which a user station, e. g. a PC, a laptop, a telephone etc. can be provided with access to a large number of services as provided over one or more service providing networks in an easy and straightforward manner. An arrangement is also needed through which the user station can be provided with access to services while still being able to take advantage of cheap tariffs, e. g. at home, and particularly by using only one subscription, particularly also while having comparatively high data transfer rates. Particularly an arrangement is needed through which a user station can be provided with multiple simultaneous access bearer connections of different types, bandwidths, QoS etc. in an easy manner.

Particularly it is an object of the invention to provide an arrangement able to take advantage of the possibilities as provided by e. g. Bluetooth, WiMAX or a OFDM (Orthogonal Frequency Division Multiplex) based radio access network and at the same time take advantage of the widespread service offer provided by

and the capabilities of for example 3G networks, i. e. multimedia real time services, particularly 3G services of any kind in general, particularly WCDMA, UMTS.

A method through which one or more of the above mentioned objects can be fulfilled is also needed.

Therefore an arrangement as initially referred to and having the characterizing features of claim 1 is provided. The arrangement particularly comprises a radio access network control node, which actually can be said to be based on the principles of an RNC (Radio Network Controller) node of a 3G system, as a separate addition to such an RNC or as an RNC with an extended functionality.

A method as initially referred to is therefore also provided, for providing a user station supporting, e. g. Bluetooth (or WiMAX, etc. ), with access to services of one or more service providing networks or service providers, which has the characterizing features of claim 21.

Advantageous embodiments are given by the appended subclaims.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will in the following be further described, in a non-limiting manner and with reference to the accompanying drawings, in which: Fig. 1 schematically illustrates a radio access network control node (RANCN) according to the invention through which user stations are given access to 3G/UMTS circuit switched/packet switched core networks over Bluetooth,

Fig. 2 illustrates a node as in Fig. 1 providing a user station with Bluetooth access to services, and mapping of services onto access bearers, Fig. 3 is a block diagram of the RRC, RLC, MAC protocol layers over Bluetooth, Fig. 4 is a block diagram schematically illustrating the functional entities of a Bluetooth capable user station, Fig. 5 schematically illustrates an RANCN in the form of a functional block diagram, Fig. 6 is a schematical view of the hardware of an RANCN as in Fig. 5, Fig. 7A is a simplified signalling diagram of a connection control (RRC) connection setup procedure, Fig. 7B is a simplified signalling diagram of an access bearer setup procedure, Fig. 8 is a more detailed signalling diagram between a Bluetooth capable user station and a 3G network, Fig. 9A is a protocol diagram describing the protocols used in the user plane between a Bluetooth capable user station and a packet switched core network, Fig. 9B is a protocol diagram describing the protocols used in the user plane between a Bluetooth user station and a circuit switched core network,

Fig. 10A is a protocol diagram as in Fig. 9A for the control plane for a packet switched core network, Fig. 10B is a protocol diagram similar to Fig. 9B but for the control plane for a circuit switched core network, Fig. 11 schematically illustrate the provisioning of media services across radio interfaces to a Bluetooth capable user station, and Fig. 12 schematically shows the provisioning of a network capable of transmitting media services across multiple interfaces to a plurality of user stations.

DETAILED DESCRIPTION OF THE INVENTION Fig. 1 is a block diagram illustrating a radio access network control node RANCN 3 according to the present invention which is provided between wireless access stations, here Bluetooth Home Base Stations, HBS 2A, 2B and an UMTS core network, particularly a circuit switched core network CS CN 10 and a packet switched core network PS CN 20, the interface used to the RANCN being the Iu- interface. The user stations are here a Bluetooth capable telephone 1A and a Laptop 1B.

The RANCN 3 is a new node which can be seen as a modified RNC, radio network controller node, which may be an RNC with an extended functionality, here called RANCN, or a separate node connected to an RNC. The interface I/f-2 between HBS: s 2A, 2B and the RANCN 3 is an adapted interface in which the protocols RRC/RLC/MAC/UDP/IP/L1 are adapted to enable communication over a Bluetooth air interface. I/f-1 is also an adapted interface with adapted protocols RRC/RLC/MAC/UDP/IP/Bluetooth (BT) for communica-

tion between the user stations, in this case telephone 1A and laptop 1B, and RANCN 3. It can be seen in the figure that the user stations 1A, 1B are connected over Bluetooth to for example an UMTS network (CS CN 10 and PS CN 20 respectively) through the RANCN node 3, HBS: s 2A, 2B being connected over e. g. Ethernet to RANCN 3. The role of the HBS is to relay the RRC/RLC/MAC/UDP/IP over the transport technology used between the HBS and the RANCN.

The HBS: s are not controlled by the RANCN. They are transparent access stations to the broadband network. Adapted 3GPP protocols L3 RL RRC and L2 RLC/MAC can be said to be reused over the Bluetooth air interface such that they meet the Bluetooth specifications, which means that the user stations 1A, 1B can be given access to a service providing network. UMTS or 3G operator networks are only examples of service providing networks, a service provider (network) according to the concept of the present invention can in principle be any network which is capable of providing capability of setting up services (bearers) of variable bandwidth and/or QoS and/or type or of different bit rates.

In the user stations some new communication software is needed.

This software particularly contains the protocol stacks as referred to above and as will more thoroughly discussed below, in order to be able to communicate with the UMTS network (or any other service providing network) through the establishment of different types of access bearers.

The RANCN 3 will be more thoroughly discussed below and particularly with reference to Figs. 5 and 6.

According to the invention Bluetooth (or WiMAX or an OFDM based radio access network or WLAN) can be said to be used as a broadband access network for a UMTS network or any of the service providing networks as discussed above. It makes it possible to

access all available 3G services and real time services like voice and video calls over e. g. Bluetooth. Of course the solution according to the invention is applicable to any services as also discussed above.

In brief it could be said that simplified W-CDMA L3 (layer 3) RRC (Radio Resource Control protocol) and L2 (layer 2) RLC/MAC (Radio Link Control protocol/Medium Access Control protocol) are used over the Bluetooth core protocols, L2CAP, Link Manager, Baseband, Radio radio/air interface (or for WLAN, LLC, MAC, PHY, (Logical Link Control protocol, Physical Layer), which however is not shown in the Figure) between the Bluetooth (WLAN) user station and the RANCN 3. These protocols are tunneled transparently through the HBS: s 2A, 2B connected to the RANCN 3. These sets of protocols will be used to set-up simultaneous multiple access bearers and to access the, in this case, UMTS core networks 10,20 using the Iu interface. The RANCN 3 can be said to be based on a W-CDMA radio network controller RNC (or comprise an RNC with an extended functionality) and it controls access bearer set-up and release between a Bluetooth capable user station and (here) a UMTS core network by reusing the above mentioned protocols (RLC/MAC and RRC).

The RANCN 3 can be seen as gateway node be-tween the Bluetooth HBS: s and the Iu interface to the (here) UMTS core network. US Patent Application 60/462703 filed on April 15th, 2003 by the same applicant, discloses a modified node denoted ANCN and it is used to provide telecommunication and/or media services to a fixed location device or a stationary equipment unit. The content of this document is herewith incorporated herein by reference. The access network control node ANCN described in the patent application referred to discloses establishment of multiple access bearers to a stationary equipment unit which is connected to the

Access Network Controller Node via an essentially fixed location physical link and the access node, ANCN, is connected to one or more external networks, for example service provider networks.

RANCN in the present application instead provides communication over e. g. Bluetooth and gives Bluetooth capable user stations the possibility of accessing services or service providing networks as discussed above. W-CDMA L3 RRC and L2 RLC/MAC are reused over Bluetooth radio interface between the Bluetooth user station and RANCN 3. These protocols will be tunneled through the Bluetooth HBS. The HBS is connected to the RANCN over a broadband VLAN (Virtual Local Area Network) connection. This set of protocols will be used to set up simultaneous multiple access bearers and to access the UMTS core network with the Iu interface. The new network node RANCN is based on W-CDMA Radio Network Controller RNC, an extended RNC. It controls Access Bearer set up and release, between a 3G UE (user station) (via Bluetooth HBS and IP network) and the UMTS core network by reusing the RLC/MAC and RRC protocols.

WCDMA L3 RRC, L2 RLC/MAC protocols are thus reused and RANCN acts as a gateway node between the Bluetooth HBS and the Iu interface to the UMTS core network. Using e. g. Bluetooth, the user can be offered both real time services/conversational services like speech and video, and the best effort services. The solution integrates home and indoor and public Bluetooth hotspots with 3G networks. Bluetooth (version 1.2) provides a transport mechanism for communication between UE (user station) and HBS. Over Bluetooth Core layer RLC/MAC, RRC are run over UDP/IP. These protocols will secure dynamic establishment of different types of access bearers with different bit rates and QoS requirements over Bluetooth, and the mix of circuit switched and packet switched access bearers over the Bluetooth radio links. The RLC, MAC will

secure the QoS of real time applications by handling different types of access bearers. The RRC control plane protocol allows the user station to access the UMTS network. The Bluetooth link Layer used to transport the Signalling and Access Bearers (RRC/RLC/MAC protocols) will be the Asynchronous Connectionless Link (ACL).

This has a bandwidth when working in symmetric mode of 432 kbps (both uplink and downlink). This is sufficient to support Access Bearers of the 3G services including the overhead of MAC and RLC and IP layers. ACL also provides a small retransmission delay and favours asymmetric services with variable bandwidths. A modified RNC, RANCN 3 is introduced between the Bluetooth HBS and the UMTS core network. Adaptations to the Bluetooth SW are needed in the User Equipment (user stations 1A, 1B). This new SW must access the existing 3G RRC/RLC/MAC protocol stacks in the 3G part of the phone. Communication with the UMTS network, and establishment of access bearers is here done over UDP/IP over Bluetooth.

In another embodiment the wireless radio access network comprises a WLAN. Briefly WLAN can be said to be Ethernet over radio. The wireless LAN 802.11 has been designed such that any LAN application or protocol including TCP/IP will run on an 802.11 wireless LAN as easily as they run over Ethernet. The data link layer within IEEE 802. 11b consists of two sub-layers, namely the Logical Link Control (LLC) and the Medium Access Control (MAC).

IEEE 802.11 uses the same IEEE 802.2 Ethernet LLC and 48-bit addressing as other IEEE 802 LAN: s, allowing a very simple bridging from wireless to wired networks according to IEEE, but the Medium Access Control sublayer is unique to WLAN. The physical layer and LLC and MAC constitute 802.11 WLAN. On the top thereof is the network layer TCP/IP, UDP/IP (Transfer Control Protocol/Internet Protocol, User Datagram Protocol/Internet Protocol).

Thus, according to the present invention RLC/MAC, RRC are run over IP, but IP is run over Bluetooth core protocols (or for WLAN, over IEEE 802. 11b instead of Ethernet).

In advantageous implementations, these protocols allow dynamic establishment of different types of access bearers with different bit rates, and QoS requirements over Bluetooth and a mix of circuit switched and packet switched access bearers over Bluetooth. RLC, MAC assures the QoS of real time applications in that they handle different types of access bearers and the RRC control plane protocol allows the user equipment to access the UMTS network.

It should be clear that the inventive concept is applicable to other protocols than RLC, RRC, which however must have substantially the same structure or functionality.

Fig. 2 schematically illustrates an example of a (media) access network with a new set of access bearers. Particularly the figure illustrates mapping of services onto access bearers. A Bluetooth capable user station 1 is connected through Bluetooth to an RANCN 3 over HBS 4. The connection from user station 1 to RANCN 3 goes over Bluetooth, relayed through HBS 4 and then over a broadband network to RANCN 3. Fig. 8 is a signalling diagram describing the signalling between user station and HBS, HBS and RANCN and, in this case, a 3G network.

RANCN 3 can be connected to one or more external networks, particularly service providing networks 10,20, 30, 40, 50. In the illustrated embodiment RANCN 3 is connected to a core network supporting the Iu interface, Iu CS and Iu PS for circuit switched and packet switched communication, respectively. RANCN 3 is here connected across an Iu CS interface to a circuit switched

(connection oriented) external network 10, across an Iu PS interface to a packet switched (connectionless) external network 20, to a Broadband Remote Access Server (BRAS) edge router 30, to a video on demand service network 40 and to a live television service network 50.

The core networks typically provide the traditional telecommunications core functions, such as subscription authentication, billing, routing etc.

It should be clear that an RANCN 3 could be connected to one or more of the illustrated networks, to other networks, in principle to any combination of service providing networks, or to a single service providing network. Particularly the service providers network is a UMTS/WCDMA 3G network, a WCDMA 2000 3G network, a BRAS IP services provider network, etc.

In this application, an access bearer is taken to mean a logical connection with the user station 1 through the (media) access network controlled by RANCN 3. One access bearer may for example support one speech connection, whereas one of the other bearers supports one video connection and a third access bearer supports one or more data packet connections. Each access bearer is associated with quality of server (QoS) parameters describing how the data stream should be handled. Examples on QoS parameters are data rate, variability of data rate, amount and variability of delay, guaranteed versus best effort delivery, error rate etc. In the (media) access network an access bearer provides the ability to process and transfer user data with a variable bit rate and different QoS requirements through the RANCN 3 and between the Bluetooth capable user station 1 and the Iu interface.

The media access network, particularly by means of providing access through the RANCN 3 over, here, Bluetooth, is able to give the user station 1 access to a plurality of different media services. For exemplifying reasons it is shown in Fig. 2 that the user station 1 may be executing for example telephony services, video services, speech services, data services and x services meaning any other services not particularly denoted.

A number of types of services or combinations of service types may be operating at any moment in time.

Through the present invention it is made possible for e. g. a Bluetooth capable user station to access a plurality of services over Bluetooth. Two or more access bearers may be used substantially simultaneously. Generally the different access bearers have different bandwidth and different QoS. Thus, bandwidth on demand can be said to be provided to the user station 1. Connection bearers may carry one or more plural services of the same type.

For reasons of clarity only one user station is illustrated in the figure. Of course several user stations may be connected to RANCN 3. As referred to earlier in the application, and as it will be more thoroughly described below, RANCN adapts and reuses protocols on the external network, particularly RLC, MAC and RRC, and these protocols are relayed over, in this embodiment, the Bluetooth HBS (Home Base Station) 4 substantially transparently.

Fig. 3 schematically illustrates the concerned protocol layers.

The (media) access network shown in Fig. 2 has a physical layer LI which comprises a physical layer, Bluetooth core. For other wireless radio access network, e. g. WLAN, it is of course other physical layers that are relevant. The protocol layers above the

physical layer Ll are the data link layer, layer L2, and the network layer, layer L3. Layer L2 is split into two sublayers. In the control plane, layer L2 contains two sublayers, the first sublayer with the medium access control (MAC) protocol, and a second sublayer with the connection control (RLC) protocol.

Between the physical layer Bluetooth core and RLC/MAC layer is the UDP/IP layer. Layer 3 has e. g. the RRC (Radio Resource Control protocol) which belongs to the control plane. Layer 2 and layer 3 correspond to the layers of UTRAN, the UTRAN layers e. g. being described by Holma and Toskala, WCDMA For UMTS Radio Access For Third Generation Mobile Communications, John Wiley & Sons, Ltd., 2000, which herewith is incorporated herein by reference.

The IP layer offers services to the MAC layer via transport channels which are characterized by how and with what characteristics the data is transferred. The MAC layer in turn offers services to the RLC layer (or more generally to the link control layer) by means of logical channels. The logical channels are characterized through the type of data they transmit. The RLC layer offers services to higher layers via service accessing points which describe how the link control (RLC) layer handles the data packets. On the control plane, the RLC services are used by the RRC layer (Connection Control layer) for signalling transport.

On the user plane, the RLC services (link control) are used by higher-layer user plane functions (e. g. speech codec. ) The RLC (link control) services are called signalling bearers in the control plane and access bearers in the user plane.

For the access network (media access network in a preferred implementation), the control interfaces between the connection control (RRC) and all lower layer protocols are used by the connection control (RRC) layer to configure characteristics of the lower layer protocols, e. g. transport and logical channels.

In the medium access control MAC layer the logical channels are mapped to transport channels. The MAC layer is also responsible for selecting an appropriate transport format for each transport channel depending on the instantaneous source rates of the respective logical channels. The transport format is selected with respect to the transport format combination set which is defined by the admission control for each connection.

In the (media) access network e. g. the RRC and MAC configuration parameters are adapted to the physical layer speed and to the transport protocol (UDP/IP). Examples of such configuration parameters are RLC PDU size, MAC PDU size, TTI (Transmission Time Interval) and TFS (Transport Format Set). These parameters are considered as configuration data and are configured in RANCN 3 for every type of access bearer.

Each transport channel is configured with a set of transport formats (TFS) which means that TFS is a set of allowed transport formats for a transport channel. A transport format describes how data is transmitted on a transport channel. A transport format contains a number of bits that should be sent in a transport channel for a certain transmission time interval. Different transport format alternatives can be sent over a transport channel and the amount of data that can be sent on each transport channel is restricted by a transport format combination set listing all possible transport format combinations.

Thus, MAC is given a limited set of transport format combinations and each transport format combination is a combination of currently valid transport formats at a given point of time, containing one transport format for each transport channel.

For each transmission time interval, the MAC entities select a transport format combination TFC from the listed set and requests the relevant PDUs from e. g. RLC buffers. The MAC then delivers PDUs from RLC buffers, adding the MAC header and tagging a UDP/IP address. A new transport format combination may also be selected due to the traffic intensity from the Core Network.

The access bearer establishment and release function (for the logical channel DTCH) and the RRC connection handling function (for the logical channel DCCH) provide MAC with the transport format combination set which MAC then uses to schedule the transport block or MAC frame by selecting a transport format combination from the set.

Each set of transport blocks allowed to be sent during a transmission time interval related to one transport channel is carried on to one IP packet transport bearer. The number of transport blocks for each transport channel is variable depending on the load on the link during the relevant transport interval.

Every DCH transport channel for one user station 1 will have one UDP/IP address, but the size of the IP packet is variable, e. g. containing any number of transport blocks.

As referred to above, the data transfer services of the MAC layer are provided on logical channels. A set of logical channel types is defined for the different kinds of data transfer services offered by MAC. Each logical channel type is defined by the type of information transferred. A general classification of logical channels is into two different groups, namely control channels, which are used to transfer control plane information, and traffic channels, for transfer of user plane information.

RANCN 3 controls access bearer set up and release between the user station 1 and the external networks 10,20, 30, 40, 50.

Particularly the set up and release of access bearers is in conjunction with RLC/MAC and RRC protocols, or more generally a link control protocol/MAC and connection control protocol.

Through the RANCN 3 there is a dynamic establishment of different types of access bearers, wherein the different access bearers might not have the same bit rates and the same QoS requirements, but are carried on the same radio access network, e. g. Bluetooth.

For each service type there may be several simultaneous sessions and thus a plurality of simultaneous access bearers. RANCN 3 moreover allows for a mixing of circuit switched and packet switched access bearers. This is independent of the physical layer over Bluetooth and Layer 1 transport technology.

The user station (cf. e. g. Figs. 1, 4) comprises, in one implementation, functional entities comprising a communication termination entity 1C, a terminal adapter 1C2, a set of run applications and a USIM card ICi may be introduced.

It should be clear that this merely relates to one particular implementation. However, in this exemplifying embodiment, communication termination entity 1C includes the functionality and the communication protocols to connect to the access network and one or more core networks. The terminal adapter 1Cz generally acts as an adaptation between the communication termination 1C and applications, cf. data services, speech services, video services, x type services etc.

The communication termination entity channel 1C in this embodiment includes control management functions CM 51, session management functions SM 52, mobility management functions MM 53 and a

protocol stack 50. In one implementation which utilizes the IP and DCH transport channel, the protocol stack 50 includes the following protocols/entities: connection control protocol RRC 54, link control protocol RLC 55, MAC-d protocol 56, UDP IP (Internet Protocol) 57, L2CAP 58, Link Manager 59, Baseband and Radio 60 wherein L2CAP, Link Manager, Baseband and Radio 58-60 here meet the Bluetooth interface specifications or IEEE 802.15. In a WLAN implementation LLC, MAC, PHY would meet the WLAN specifications IEEE 802. 11b, whereas for an OFDM implementation or WiMAX the IEEE 802.16 specifications would be met.

The terminal adapter 1C2 provides communication with the applications (data services, speech services etc. over an application program interface API for data service, an API for speech, an API for video and API: S for service types x.

Of course these are merely examples and there may be more or less APIs depending on which services that are wanted.

The RANCN 3 provides a common access interface to establish multi access bearer channels to each user station (not shown in the figure). RANCN 3 advantageously utilizes different types of access bearers dynamically, e. g. establishing and/or allocating as needed an appropriately configured access bearer. Particularly RANCN establishes or allocates the access bearer for example in response to an initiation of a media service at the user station 1. The access bearers are established using layer L2 and layer L3 protocols. The access bearers can also be established to provide a mix of circuit switched access bearers and packet switched access bearers simultaneously with different QoS etc. The access bearers are established dynamically by RANCN 3 using the RRC protocol and the RLC/MAC protocol for the access bearer user plane, or more generally a connection control protocol and a link control

(manager) protocol of the access network for the access bearer user plane.

In the embodiment illustrated in Fig. 5, RANCN 3 comprises a connection control unit 130 and a bearer service processing unit 140. The connection control unit 130 establishes access bearers for providing services to the user station and in one embodiment implements the RRC protocol. The bearer service processing unit 140 maps multiple simultaneous access bearers into packets of a transport protocol of the physical link of physical layer LI and here implements the L2CAP/Link Manager protocol of the access network. In one implementation the multiple simultaneous access bearers are mapped into packets of the transport protocol relayed over HBS 4 using Bluetooth.

RANCN comprises a port 150 for the physical layer Ll communication. It should be clear that port 150 may be the termination point of many HBS: s or AP: s and not only for a single HBS or AP. Port 150 may be external to the RANCN or it may be internal. Further RANCN 3 may include interfaces 121-125 toward CS, PS Core Networks, BRAS edge router, to video on demand network etc. The connection control entity (RRC) 135, link control entity (RLC) 145, MAC protocol entity 146 and LI protocol entity 151 are used for data services, cf. Fig. 2.

Port 150 is a port to a Bluetooth HBS 4. Every user station is connected to an appropriate Link Manager entity in RANCN 3, typically the Link Manager entity is included in the bearer service processing unit 140.

In one embodiment RANCN comprises a switched-based node having a switch 134 (cf. Fig. 6). The switch 134 serves to interconnect

other constituent elements of RANCN. It may for example be an ATM switch or a packet switch.

The other constituent elements may include one or more extension terminals 1351-135X. The extension terminals may include the functionality to connect RANCN to plural user stations served by it. The extension terminals may connect RANCN over Iu-CS interface to the circuit switched core network, over Iu-PS to the packet switched core network, to the BRAS edge router, to data services etc. (121A-124A).

Other such constituent elements may include a packet control unit PCU 140, a codec pool 141 (in the following simply referred to as codec 141), a timing unit 142, data services application unit 124A and a main processor 131. Of course not all these elements are necessary for the functioning of RANCN. Codec 141 is for example useable for CDMA 2000, but not necessary for for example WCDMA.

Generally the functionality and need of constituent elements can be appreciated by the man skilled in the art.

The packet control unit PCU 140 provides e. g. for separation of packet switched data and circuit switched data when it is received from the user station and multiplexes the different data streams from circuit switched and packet switched core networks onto common streams. The PCU may alternatively be located externally of the RANCN.

The functionality of the connection control unit and the bearer service processing unit can be executed or performed by main processor 131, or also by another processor of the RANCN node or by different processors. The functions of these units can be implemented in many different ways using individual hardware

circuits, using software functioning in appropriate manner, using application specific integrated circuits and one or more digital signal processors etc.

According to the invention RANCN can be said to be an adapted or modified RNC node of a UTRAN. RANCN can be said to reuse modified UTRAN RLC/MAC and RRC protocols. A corresponding functionality may also be provided in separate means connected to a conventional RNC.

The IP (Internet transport protocol) has to be supported in RANCN as a transport protocol for the access bearer channels.

Fig. 7A describes the connection control (RRC) connection setup procedure. After deblocking of the Bluetooth (BT) user station 1 and upon initiation of an instance of one of the media applications in the application set, as the first action 101 for setting up a connection control (RRC) connection the user station 1 transmits a connection request message to RANCN 3. The connection request message 101 is sent over the DCCH channel from user station 1 to RANCN 3. The connection request message 101 includes a transport information element or traffic descriptor. In the case of IP transport, the traffic information element can be, <BR> <BR> e. g. , a UDP/IP address. The transport information contains the necessary information to map every type of access bearer to the transport bearers (IP packets) RLC PDU size, MAC PDU size, TB transport blocks size to be sent over a transport bearer during a TTI = Time to Transmission Interval, TTI, etc. For IP there is no reservation of bandwidth. Conventional UTRAN related information elements are not used or included in the connection request message 101.

RANCN 3 then establishes or allocates protocol entities in layer L1, layer L2, and layer L3 for the application initiated at the user station 1.

For the IP transport protocol, no reservation of bandwidth is done, but the number of simultaneous access bearers (ABs) on a specific connection could be limited at connection control (RRC) connection set up after a capacity check. That is, for the IP transport protocol, the RANCN can check the traffic load on the access network towards the user station and check the number of access bearers already established as well as their types and their bit rates, and decides whether to accept new access bearer set up or not.

After receipt of the connection request message 101 and establishment of the protocol entities RANCN 3 transmits a RRC connection setup message 102, to user station BT 1. The connection setup message 102 is thus sent by the (media) access network to indicate acceptance and establishment of a connection control connection for the user station. Like message 101, the connection setup message 102 is transmitted over the DCCH channel.

The connection setup message 102 includes assignment of control link information, and transport channel information. Unlike the UTRAN RRC connection setup message, the connection setup message 102 of the media access network does not contain radio resource information.

After receipt and processing of the connection setup message 102, the user station BT 1 uses the information obtained from connection setup message 102 to establish protocol entities 102A which correspond to those established at action 102 at RANCN 3.

Then user station BT 1 transmits a RRC connection setup complete

message 103 to RANCN 3. This message serves as the confirmation by the user station 1 of the establishment of the connection control (RRC) connection. The connection setup complete message 103 is also sent using a DCCH logical channel.

On receipt of message 103, the RANCN 3 has set up a signalling channel which is analogous to a signalling radio bearer (SRB) in WCDMA. Once the signalling access bearer (SAB) is set up, the first action of the user station 1 (after establishing the connection for the first time after a period of being switched off <BR> <BR> (off state) ) is to perform a location update signalling procedure.

This is a signalling sequence between the user station 1 and the core network on the Non Access Stratum level. By this action, the user station BT 1 becomes registered as being active in the service providers network. The user station 1 is then considered active (analogous to being in state cell DCH connected in WCDMA RRC protocol definition). This describes just one possible embodiment, there being different or parallel solutions which use the common channel concepts and PCH, FACH and RACH channel concepts. The user station 1 is then connected and is ready to accept terminating calls and make originating calls, in the case of being connected to a WCDMA core network. In other examples of service providing networks this takes the form of the user station 1 being able to communicate, request and receive, terminate media and data services by using non access stratum messages embodied in the payload of the connection control (RRC) direct transfer messages.

With reference to Fig. 7B an access bearer setup procedure will be described. Once the user station is connected to RANCN 3, the access bearer (AB) is allocated or established. The skilled man will understand the various considerations involved in the RANCN 3 determining which access bearer to assign. For example can

considerations and/or criteria such as those employed in UTRAN be utilized.

After establishing the signalling access bearer, RANCN 3 sends a access bearer setup message 201 to user station BT 1 for the purpose of establishing the access bearer (s). The access bearer setup message 201 is transmitted over the DCCH logical channel.

The type of access bearer is included in the access bearer setup message 201, and the message 201 includes the transport information element (e. g. UDP/IP address for IP transport). The access bearer setup message 201 also contains an identification of the access bearer.

The access bearer setup message 201 may resemble the comparably named UTRAN message known as the radio bearer setup message.

Upon receipt of the access bearer setup message 201 the user station BT 1 is advised of the pertinent access bearer information. Then, user station BT 1 acknowledges receipt by transmitting an access bearer set up complete message 202. The access bearer setup complete message 202 is thus sent by user station BT 1 to confirm the establishment of the radio bearer. It is sent over the DCCH logical channel. As in previously described connection control messages, the PhyCH information element can be appropriated to refer to transport channels (e. g. to carry the UDP/IP address of the transport channels).

After the access bearer to be utilized by an application service has been established in the manner generally described above, data packets belonging to the media service of the application can be transmitted from and to user station BT 1 over Bluetooth. The further description of protocols affirms the processing of the data packets.

Fig. 8 is a signalling diagram illustrating the signalling between the user station, HBS, RANCN and, in this case, a 3G network.

It is then supposed that the Bluetooth capable user station sends a Bluetooth connection request to the HBS, 301. This means that a Bluetooth connection will be established. The HBS then returns an acknowledgment, 302, of the connection to the user station. The user station then sends an initiate IP session request, 303, to RANCN, where UDP/IP is established and an acknowledgment 304 is returned to the user station. Subsequently the user station sends an RRC connection request, 305, to RANCN, as also explained in Fig. 7A in a more detailed manner. When RANCN has established RRC/RLC/MAC, a message to that effect is sent to the user station, 306. A message is then also sent to the 3G network and RANAP/SCCP is established. Between the user station and the 3G network non- access stratum messages (NAS) are sent, here indicated through numeral 308. Such messages may comprise location update, access bearer setup etc. , cf. for example Fig. 7B. The user station then sends a (RANAP) location registration request, 309, to the 3G network which returns a (RANAP) location update accept, 310, to the user station. Subsequently the user station uses RRC sending a CM service request to RANCN, 311. RANCN, over RANAP, sends an initial UE (User Equipment) message, 312, to the 3G network (i. e. a CM service request).

The 3G network then sends a CM service accept, i. e. a RANAP direct transfer, 313, to RANCN, which uses RRC to send a CM service accept to the user station, 314. The user station uses RRC to send an uplink direct transfer (setup) request 315 to RANCN, and further to the 3G network using RANAP, 316.

Figs. 9A, 9B, 10A, 10B show protocol stacks for the user plane for the packet switched and the circuit switched cases respectively (Figs. 9A, 9B) and the control plane protocols for the packet switched and circuit switched cases (Figs. 10A, 10B respectively).

Thus, Fig. 9A illustrates the protocol stacks of a Bluetooth capable user station, HBS, RANCN and a packet switched core network, PS CN and the interfaces there-between indicated. APP in the figure relates to applications for the transportation of user data. The grain shaded protocols are the Bluetooth protocols whereas upward diagonal-shaded protocols are the protocols terminating on the RANCN.

As can be seen the Iu-PS (packet switched) interface is used between PS CN and RANCN, whereas new interfaces are introduced between the Bluetooth capable user station and the HBS and between the HBS and RANCN respectively. In this implementation RRC, RLC/MAC are run over UDP/IP over the Bluetooth protocols. The user plane information is segmented/concatenated over the RLC/MAC protocols. The role of the RLC protocol is to communicate or concatenate and prioritize the information from the higher layers whereas the role of MAC is to map the RLC frames to the transport channel MAC frames which are encapsulated into UDP/IP frames. This will also be further discussed below. However, between the user station and the HBS, the Bluetooth interface and protocols are used. It consists of the radio layer, L2CAP, Link Manager and the Baseband layer (cf. IEEE 802.15). RRC, RLC/MAC and UDP/IP are according to the present invention run over the Bluetooth protocols.

Fig. 9B is a figure similar to Fig. 9A with the difference that the core network is circuit switched. The interface between RANCN and CS CN is thus the Iu-CS interface. The user data may e. g. be

voice and/or Unrestricted Digital Information (UDI) or streamed data.

In Fig. 10A the protocols for the packet switched control plane between a Bluetooth capable user station and a packet switched network are illustrated. The user station needs to communicate with the PS CN transparently through the RANCN, as in UMTS with no substantial modification. The Call Control (CC), Mobility Management (MM), Session Management (SM) are used. This is done through a communication channel. The functionality of RRC is to establish the communication channel between the Bluetooth capable user station and the RANCN, and the purpose of RLC is to segment or concatenate and prioritize the information from the higher layers. MAC serves the purpose to map the RLC frames to the transport channel MAC frames which are encapsulated into UDP/IP frames etc. These frames are then run over the Bluetooth interface between the user station and the BT access point (HBS). The BT access point (HBS) simply relays these frames and then run them over the Ethernet/radio link between the Bluetooth access point (HBS) and the RANCN. It does not necessarily have to be Ethernet, it could just as well be ATM or any other technology. As in Fig.

9B, for the user plane, the concept is the same with the difference that RRC is not used as compared to the user control plane. The user plane information is segmented/concatenated over the RLC/MAC protocols etc.

In the following the user plane protocol operation will be briefly described. In the user plane, in the (media) access network according to the invention, Iu UP, RLC and MAC (e. g. MAC-d) are used substantially in the same manner as in UTRAN. A transmission time interval (TTI) is assigned to every DCH established for MAC policing. In the transmitter TTI timeouts are aligned, i. e. all TTI timeouts coincide for every largest TTI interval. After the

TFCS (Transport Format Combination Set) scheduling algorithm has been run, transport blocks are framed into IP packets and sent towards the receiver. No TTI is defined for the receiver, i. e. blocks contained in IP packets are passed at once towards higher layers.

MAC size (TB transport block) and TTI length are access bearer and transport bandwidth specific. They are configurable depending on the physical layer speed. If for example there is to be a higher bandwidth transport, the MAC size (TB) for a certain access bearer can be set larger if there is a possibility to send more bits during the same time period. For the IP transport protocol no bandwidth reservation is needed but the number of simultaneous access bearers on a specific connection could be limited at access bearer set up after a capacity check in RANCN.

In the following the operation of a generic link control entity, e. g. the RLC protocol, will briefly discussed. The RANCN comprises a bearer service processing unit with a generic link control entity. The RLC (link control) entity has a transmitting side and a receiving side. The transmitting side has, among others, a segmentation/concatenation unit, a transmission buffer and a PDU formation unit. The receiving side has among others a receiving buffer and a reassembly unit. In view of the respective units, the RLC layer architecture provides segmentation and retransmission services for user as well as for control data.

On the transmitting side of an RLC entity in RANCN, data packets received (RLC SDU) from higher layers via SAP are segmented and/or concatenated by a segmentation/concatenation unit to payload units of fixed length. The payload unit length is a semi static value that is decided in the access bearer set up procedure and can only be changed through an access bearer reconfiguration procedure. For

concatenation purposes, bits carrying information on the length and extension are inserted into the beginning of the last payload unit where data from an SDU is included. If several SDUs fit into one payload unit, they are concatenated and the appropriate length indicators are inserted at the beginning of the payload unit. The payload units are then placed in a transmission buffer which also, in this particular embodiment, handles retransmission management.

In case of a higher bit rate speed, the RLC can work in transparent mode TM, in an unacknowledged mode UM and acknowledged mode AM. In the AM, a retransmission protocol is used and received, erroneous packets are retransmitted. Mode as well as RLC PDU size are configurable. In the transparent mode no protocol overhead is added to the higher layer data. An erroneous LC PDU can be discarded or marked erroneous. Transmission with limited segmentation reassambly capability can be accomplished. An RLC PDU may be constructed by taking one payload unit from the transmission buffer. For the transparent mode, an RLC PDU header contains the RLC PDU SN sequence number (12 bits) and optionally a length indicator used for the concatenation purposes.

In the unacknowledged mode no retransmission protocol is in use.

Received erroneous data is either marked or discarded depending on configuration. The RLC SDU that is not transmitted within a specified time period is simply removed from the transmission buffer. The protocol overhead is three octets and the size of the RLC PDU could be larger. The size of the RLC PDU can be adjusted based on the layer Ll transmission speed.

Below the MAC layer protocol will be briefly discussed. The MAC layer with its MAC-d protocol entities performs a functionality as in the case when the physical layer is the WCDMA radio interface.

In the MAC layer the logical channels from the RLC (link control) layer are mapped to the transport channel MAC frames (e. g. to MAC

PDUs). In the layer 1 protocol the transport channels MAC frames are encapsulated into UDP/IP packets. There is a mapping between different layers for different access bearers when the physical layer is an IP layer. The RLC sub-layer may comprise a number of access bearers. Every access bearer or MAC frame may have two UDP/IP addresses when the IP transport protocol is used, i. e. one UDP/IP address for the user station and one UDP/IP address for RANCN.

The MAC header is a bit string with a length which not necessarily is a multiple of 8 bits. The MAC protocol might be simplified by reducing its four headers to one header. Of the traditional four headers, the TCTF (Target Channel Type Field) header, the C/T, Logical Channel Instance header and the UE-Id (Ue Identification) type header are not used in the simplification but only the UE-Id header could be used, particularly having a maximum of 16 bits.

In the transport network, i. e. in the lowest layer, the MAC frames are encapsulated as in the WCDMA into appropriate packets/frames.

Particularly the MAC frames are encapsulated into IP packets.

Thus, the MAC sublayer has to be adapted to interwork with the UDP/IP layer but this should be known to the man skilled in the art how such adaptations are performed.

The basic idea of the present application is to run the RRC, RLC/MAC layer over the UDP/IP layer. Any transport technology between the BT access point and the RANCN could actually be used, for example Ethernet or ATM. The role of the BT access point is simply to relay the RRC, RLC/MAC/UDP/IP by means of the transport technology used between the access point and the RANCN. Only the UDP/IP addresses are relevant for the MAC PDUs. Such an UDP/IP address represents the address of the user station with a

Bluetooth interface. This is clearly shown in the protocol diagrams, Figs. 9A, 9B, 10A, 10B.

Thus, in this embodiment the upper layer will use the L2CAP layer to establish different radio links with different QoS and bit rate. L2CAP is described in the Bluetooth Vl. 2 specification (Vol. 1).

The BT controller is assumed to have limited data buffering capabilities in comparison with the host. Therefore the L2CAP layer is expected to carry out some simple resource management when submitting L2CAP PDUs to the controller for transport to a peer device. This includes segmentation of L2CAP SDUs into more manageable PDUs and then the fragmentation of PDUs into start and continuation packets of a size suitable for the control buffers, and management of the use of the controller buffers to ensure availability for channels with Quality of Service (QoS) commitments.

The channel manager is responsible for creating, managing and destroying L2CAP channels for the transport of service protocols and application data streams. The channel manager uses the L2CAP protocol to interact with a channel manager on a remote (peer) device to create these L2CAP channels and connect their endpoints to the appropriate entities. The channel manager interacts with its local link manager to create new logical links (if necessary) and to configure these links to provide the required quality of service for the type of data being transported.

The L2CAP resource manager block is responsible for managing the ordering of submission of PDU fragments to the baseband and some relative scheduling between channels to ensure that L2CAP channels with QoS commitments are not denied access to the physical channel

due to Bluetooth controller resource exhaustion. This is required because the architectural model does not assume that the Bluetooth controller has limitless buffering, or that the HCI (Host to Controller Interface) is a pipe of infinite bandwidth.

L2CAP Resource Managers may also carry out traffic conformance policing to ensure that applications are submitting L2CAP SDUs within the bounds of their negotiated QoS settings. The general Bluetooth data transport model assumes well behaved applications, and does not define how an implementation is expected to deal with this problem.

L2CAP layer services provide a frame-oriented transport for asynchronous and isochronous user data. The application submits data to this service in variable-sized frames (up to a negotiated maximum for the channel) and these frames are delivered in the same form to the corresponding application on the remote device.

There is no requirement for the application to insert additional framing information into the data, although it may do so if this is required (such framing is invisible to the Bluetooth Core system).

There are different possibilities for how to transport the data of the access bearers for different services over the Bluetooth interface.

According to the Bluetooth Vl. 2 specificatin it is possible, using the L2CAP protocol, to define different links with different QoS and bit rate over the Bluetooth interface. Bluetooth gives the possibility of defining an Asynchronous Connectionless Link (ACL) or a Synchronous Connection Oriented Link (SCO). One possibility is to use the ACL link, which gives the possibility of transferring 432 kbps symmetric (UL (uplink) and DL (downlink))

per Bluetooth user. SCO gives the possibility of setting up 3 simultaneous conversational 65 kbps (UL and DL).

According to one alternative of transferring the signaling and access bearers a large ACL channel per user (432 kbps ACL connection, is defined with either Best Effort or Guaranteed Service Type). As long as there is only one user of the Bluetooth interface, then bandwidth and quality are guaranteed. Traffic Specification parameters (Token rate, Token Bucket Size, Peak Bandwidth) and Quality of Service parameters (Latency and Delay Variation) can be tuned to be most efficient for one Bluetooth user.

According to another alternative different channels (ACL) over Bluetooth are defined for all the different individual Access Bearer types. An advantage of this is that every access bearer is mapped to the corresponding radio link in term of QoS and bandwidth.

An additional advantage is that more than one user may be able to use the Bluetooth interface simultaneously. Different combinations of services by different users are possible.

If one large ACL is used or if many ACLs tuned to their individual Access Bearer requirements are used depends on the requirements on the WCDMA service offering and the bandwidth of the HBS Bluetooth and the number of users per HBS.

Tuning the L2CAP is described in order to show how the solution works. No impact is placed on Bluetooth implementation. Bluetooth is used unchanged.

The Service Discovery Protocol is used by the HBS and 3G Mobile phone enabling for them to recognize each other. This is part of existing Bluetooth service for browsing and querying for services offered by another Bluetooth device.

Radio Frequency, Link Controller, baseband and NAL layers are also used unchanged.

Fig. 11 shows one example of a BT user station 1'which can obtain media services either alternatively or simultaneously both over the (media) access network with RANCN 3'as discussed above (path I) and over a conventional radio access network with a RNC and a base station (path II). Here a conventional radio access network UTRAN is used. The UTRAN structure and operation should be known to the man skilled in the art. The core network service nodes are in the figure connected to a UMTS terrestrial radio access network UTRAN, over the Iu interface. The UTRAN, as is known, includes one or more RNCs and one or more BSs although here only one RNC and one BS are illustrated. Of course generally several base stations are served by each RNC etc. The BT user station 1'selectively communicates with one or more cells or one or more base stations over a radio interface to the core network.

Particularly the BT user station 1'comprises a mobile termination unit MT 11'which participates in any radio transmission of media services provided through the radio access network.

The BT user station 1'can participate in certain media services provided via for examples UTRAN and at the same time or at any other time participate in media services provided over Bluetooth as discussed earlier in the application (path I). The arrow path I illustrates that the user station 1'receives a first media service (a data service) via the media access network, i. e. over Bluetooth, and arrow path II illustrates that the user station 1'

receives a second media service, for example a speech service, over UTRAN. Bearers for the respective services are set up by the respective networks.

The radio access network and the Bluetooth can be operated by the same operator or by different operators.

Fig. 12 shows an example wherein a network operator provides media services over different interfaces, e. g. over the conventional air interface on one hand and over Bluetooth on the other hand, to the user station 1'. Here several user stations 1E, 1F, 1G are illustrated in the figure. The user stations 1E, 1F, 1G are connected to RANCN over respective HBS: s AP 4E, 4F, 4G respectively and over base stations (only user stations 1E, 1F) and RNC over UTRAN. The implementations of Figs. 11,12 are merely illustrated for exemplifying reasons; the user stations could of course be connected only over Bluetooth according to the inventive concept.

In a most particular embodiment the radio access network control node (RANCN) is provided with or communicates with storing means or a register holding information about users located in an area with given characteristics, i. e. a low tariff area, an area with a given service quality or a given QoS, an area which supports certain additional services (or which does not support certain services), etc. The user stations are particularly identified through their IMSI (p-TMSI) and each user has a list of other user stations which they allow, and by which they are allowed, to get knowledge about said user station being in a certain area or within the same area as far as a particular service, tariff, etc. is available or offered. This means that the user stations mutually have to"accept"each other to allow for exchange of information. An example of such lists are so called"buddy lists".

In an even more particular embodiment it is provided for communication between different RANCN: s for sharing of information about which IMSI: s (user stations) that are located in the RANCN environment, e. g. in the whole network of an operator (or parts of the network, or, if operators cooperate, environments according to what is allowed by the operators); e. g. all users using the same air interface technology, a particular (e. g. low) tariff, etc.

There have been recent examples of a new method in mobile subscription marketing. Today the operators offer cheaper or even sometimes free calls between subscribers within the operators'own networks. Another trend is to offer calls with cheaper tariffs when calling from a"home"environment. This is a way for mobile operators to compete with low price fixed operators and very cheap VoIP (Voice over IP) providers.

According to the present invention this technique can be further improved, as suggested above, such that users in low tariff environments (e. g. at home) may be allowed to call other users who are also in low tariff environments for a lower price or for free.

In these embodiments are thus shown a solution for giving an indication to users about which of their"friends"are also in a low tariff environment, also called"buddy service", which is a new service providing information to a user about which users he can call at a low tariff.

In known systems charging in mobile networks is split between calling party (A-party) and called party (B-party). A pays the cost for the originating leg of the call, B pays for the cost of the terminating leg of the call. It is possible to receive calling information about the charge of each leg separately. Today, mobile

network operators offer lower tariffs if calling from a"home" environment (e. g. BTs new Bluephone service based on Ericsson product Mobile@Home).

However, so far it has not been possible to provide a solution which informs the calling user of the possibility of lower charging tariff towards certain users who are also in a low tariff "home"environment.

Thus, so far it has not been possible to transfer information about how the call-destination user is connected to the calling user. Care has to be taken not to infringe on privacy of the users (giving information to other users about the location of the call- destination user).

According to the particular embodiments it is enabled to, when the user enters a low tariff environment, transfer a request about which users (buddy list) the user is interested in knowing that they also are in the low tariff environment to the network; temporarily store information in the network about the users (buddy list) the user is interested in, for the duration of the users presence in the low tariff environment; transfer the information about which users are in the low tariff environment to the user; only transfer the information about the"buddy"if the user is also him-/herself on the user's"buddy"list; and update the user with the latest information when a user on his"buddy" list enters or leaves the low cost tariff area.

The user station contains a USIM card for authentication and subscription purposes. The terminal contains the W-CDMA RRC protocol stack or the modified W-CDMA RRC protocol stack according to the present invention.

The user's terminal contains SW which enables a list of the users he is interested in ("buddy list") to be made. The list comprises a list of IMSI: s of the users.

When the user connects in the low tariff area (or an otherwise characterized area) and authentication is successful, a Location Update is done to the 3G Core network. The user becomes registered as idle and located in the RANCN.

When the user station is in ready state, a message (new RRC message: SERVICE REQUEST) is sent from user to RANCN containing the list of IMSI: s which are currently on the user's"buddy list".

When RANCN receives the buddy list, the contents are stored against the user's IMSI in a Register.

The RANCN searches in the Register of Users currently located in the RANCN and tries to locate each buddy user. If located, the buddy-user's own list of buddies is checked to see if the user is also on the buddy-user's list.

Once all IMIS: s on the buddy-list have been checked, a list of IMSI: s which are also located in the RANCN are returned to the user in a message (new RRC message: SERVICE RESPONSE).

The message is received in the user terminal equipment and an indication (e. g. an icon) is displayed on the list of users which are also in the low cost tariff area.

Every time the user modifies the buddy list, the user sends a new buddy list and the above sequence is repeated (RRC meassage: SERVICE REQUEST/RRC message: SERVICE RESPONSE).

When a new user locates on the register of the RANCN, the RANCN must scan through all buddy lists of all registered users searching for the new user's IMSI. If located, and (optional addition) if the user's IMSI is also on the buddy list of the new user, then indications are sent to both users using RRC message: SERVICE RESPONSE.

When a user leaves the register of the RANCN, the actions are similar to above. RANCN must scan through all buddy lists of all registered users searching for the departed user's IMSI. If located, then an indication must be sent to users remaining in the RANCN register that the buddy has left, using RRC message: SERVICE RESPONSE.

As referred to above, the solution can be enhanced to include communication between RANCN nodes for sharing of information about which IMSI: s are located in the RANCN environment in the whole of an operator's network (e. g. all users using the same air interface technology, lower tariff). This can be done using a new service layer message on a 3GPP Iur interface using RNSAP. (RNSAP: SERVICE INFO (new) ). Information about all new users who enter, or all users who leave, can be sent instantaneously to each RANCN. This interface also can be used continually to update each RANCN node of the IMSI: s which are on the registers of others. This refreshes the information in the RANCN and user terminals, for example in the case of information losses due to node resets.

Thus, this solution can be designed as a generic solution. It can be used not only for information about users in low tariff areas, but also used as a way of indicating possible higher service quality, additional services, additional service level, etc.

Moreover, the solution is not restricted to 3G Mobile handsets.

The terminal equipment can be any, but must contain a USIM card, 3GPP Authentication and RRC or according to the invention modified RRC protocol stack. The network node must contain SW for terminating RRC protocol. The network node must be connected over an Iu interface to a Core Network containing a 3GPP Authentication mechanism.

It should be clear that the concept of indication to a user about "associates"in a similar environment also could be implemented in conventional networks, i. e. which do not include a RANCN as disclosed herein for access e. g. via Bluetooth, WiMAX, WLAN, etc. to e. g. UMTS services.

Among others it is an advantage of the present invention that a radio access network such as Bluetooth, WiMAX, WLAN or an access network implementing OFDM can offer not only best effort services, but also real time services and conversational services like speech and video.

Yet another advantage is that e. g. UMTS (or any other service providing network) operators are given the opportunity to provide services, e. g. 3G services, over e. g. a Bluetooth radio interface by reusing the infrastructure of e. g. the UMTS.

It is among other also an advantage of the invention that it becomes possible to provide user access, over Bluetooth radio interface, to the 3G operators network and services. All 3G services will be accessible over Bluetooth including the real time, like voice and video, particularly with a predictable and secure QoS.

Further, the invention provides for services integrating indoor and public hotspots based on Bluetooth with 3G networks. It allows mobile operators to integrate Bluetooth access networks with their existing 3G network, by reusing investment made in core infrastructure, subscriber management, billing and authentication.

It should be clear that the invention, of course, is not limited to the particularly illustrated embodiments, but that it can be varied in a number of ways within the scope of the appended claims.