HK1081745B - Rrc connection request method and apparatus for mobile communications - Google Patents

Description

Radio resource control connection request apparatus and method for mobile communication

Technical Field

The present invention relates to an apparatus and method for establishing an RRC connection, which is an initial connection established between a terminal in an idle state and a UTRAN in a UMTS (universal mobile telecommunications system), and in particular, to an apparatus and method for facilitating a terminal to transmit an RRC connection request message, receive a first channel for a certain time, and if a response to the RRC connection request message is not received on the first channel, determine whether the RRC connection request message should be retransmitted based on counting state information provided via a second channel.

Background

The Universal Mobile Telecommunications System (UMTS) is a european, third generation IMT-2000 mobile communication system that has evolved from a european standard known as the global system for mobile communications (GSM). UMTS is intended to provide improved mobile communication services based on the GSM core network and wideband code division multiple access (W-CDMA) radio connection technology.

In 12 months 1998, the third generation partnership project (3GPP) was formed by ETSI in europe, ARIB/TTC in japan, T1 in the united states, and TTA in korea. The 3GPP creates detailed technical requirements for UMTS technology. In order to achieve a rapid and efficient technical development of UMTS, five Technical Specification Groups (TSG) for standardizing the UMTS have been created within the 3GPP by considering individual characteristics of network elements and their operation.

Each TSG develops, approves, and manages the standard specification in the related art. Among these groups, the Radio Access Network (RAN) group (TSG-RAN) develops a standard for the functions, requirements and interfaces of the UMTS Terrestrial Radio Access Network (UTRAN), a new radio access network for supporting W-CDMA access technology in UMTS.

Fig. 1 illustrates an exemplary basic structure of a conventional UMTS network. As shown in fig. 1, the UMTS is roughly divided into a terminal or User Equipment (UE)10, a UTRAN20, and a Core Network (CN) 30.

The UTRAN20 includes one or more Radio Network Subsystems (RNSs) 25. Each RNS25 includes a Radio Network Controller (RNC)23 and a plurality of node bs (base stations) 21 managed by the RNC 23. The RNC23 handles the allocation and management of radio resources and functions as an access point with respect to the core network 30.

The node B21 receives information transmitted by the physical layer of the terminal 10 via an uplink and transmits data to the terminal 10 via a downlink. The node B21 functions as an access point for the UTRAN20 for the terminal 10.

The UTRAN20 constructs and maintains a Radio Access Bearer (RAB) for communication between the terminal 10 and the core network 30. The core network 30 requests end-to-end quality of service (QoS) requirements from the RAB, and the RAB supports the QoS requirements that the core network 30 has set. Therefore, by constructing and maintaining the RAB, the UTRAN20 can meet end-to-end QoS requirements.

Services provided to a specific terminal 10 are roughly divided into Circuit Switched (CS) services and Packet Switched (PS) services. For example, conventional voice conversation services are circuit switched services, while web browsing services via internet connections are classified as Packet Switched (PS) services.

To support circuit switched services, the RNC23 is connected to a Mobile Switching Center (MSC)31 of the core network 30, and the MSC 31 is connected to a Gateway Mobile Switching Center (GMSC)33, which Gateway Mobile Switching Center (GMSC)33 manages connections with other networks. To support packet switched services, the RNC23 is connected to a serving General Packet Radio Service (GPRS) support node (SGSN)35 and a Gateway GPRS Support Node (GGSN)37 of the core network 30. The SGSN 35 supports packet communications with the RNC23 and the GGSN 37 manages connections with other packet switched networks, such as the internet.

Fig. 2 illustrates a structure of a radio interface protocol between the terminal 10 and the UTRAN20 according to the 3GPP radio access network standard. As shown in fig. 2, the radio interface protocol has horizontal layers including a physical layer, a data link layer, and a network layer, and vertical planes including a user plane (U-plane) for transmitting user data and a control plane (C-plane) for transmitting control information.

The user plane is an area that handles call information with the user, such as voice or Internet Protocol (IP) packets. The control plane is an area that processes control information for interfacing with a network, maintains and manages calls, and the like.

The protocol layers in fig. 2 may be divided into a first layer (L1), a second layer (L2), and a third layer (L3) by three lower layers based on the Open System Interconnection (OSI) standard model.

The first layer (L1), i.e., the physical layer, provides an information transfer service to an upper layer by using various wireless transmission techniques. The physical layer is connected to an upper layer called a Medium Access Control (MAC) layer via a transport channel. The MAC layer and the physical layer exchange data via a transport channel.

The second layer (L2) includes a MAC layer, a Radio Link Control (RLC) layer, a broadcast/multicast control (BMC) layer, and a Packet Data Convergence Protocol (PDCP) layer.

The MAC layer handles mapping between logical channels and transport channels and provides allocation of MAC parameters for allocation and re-allocation of radio resources. The MAC layer is connected to an upper layer called a Radio Link Control (RLC) layer via a logical channel.

Various logical channels are provided according to the type of information being transmitted. Generally, a control channel is used to transmit information of a control plane, and a traffic channel is used to transmit information of a user plane.

The logical channel may be a common channel or a dedicated channel depending on whether the logical channel is shared. Logical channels include a Dedicated Traffic Channel (DTCH), a Dedicated Control Channel (DCCH), a Common Traffic Channel (CTCH), a Common Control Channel (CCCH), a Broadcast Control Channel (BCCH), and a Paging Control Channel (PCCH). The BCCH provides information including information used by the terminal 10 to access the system. The PCCH is used by the UTRAN20 to access the terminal 10.

The MAC layer is connected to the physical layer through transport channels and may be divided into a MAC-b sublayer, a MAC-d sublayer, a MAC-c/sh sublayer, and a MAC-hs sublayer according to the type of transport channel to be managed. The MAC-b sublayer manages a BCH (broadcast channel), which is a transport channel that handles the broadcast of system information. The MAC-c/sh sublayer manages a common transport channel, such as a Forward Access Channel (FACH) or a downlink common channel (DSCH), which is shared by a plurality of terminals. The MAC-d sublayer manages a Dedicated Channel (DCH), which is a dedicated transport channel for a specific terminal 10. Therefore, the MAC-d sublayer is located in a serving rnc (srnc) managing the corresponding terminal, and one MAC-d sublayer also exists in each terminal.

The RLC layer supports reliable data transmission and performs segmentation and concatenation on a plurality of RLC Service Data Units (SDUs) delivered from an upper layer. When the RLC layer receives RLC SDUs from an upper layer, the RLC layer adjusts the size of each RLC SDU in an appropriate manner based on processing power, and then generates a data unit by adding header information thereto. The data units, called Protocol Data Units (PDUs), are delivered to the MAC layer via logical channels. The RLC layer includes an RLC buffer for storing RLC SDUs and/or RLC PDUs.

The BMC layer arranges a Cell Broadcast (CB) message list transferred from the core network and broadcasts the CB message to the terminals 10 located in a specific cell.

The PDCP layer is provided on the RLC layer. The PDCP layer is used to efficiently transmit network protocol data, such as IPv4 or IPv6, over a radio interface having a relatively small bandwidth. For this purpose, the PDCP layer reduces unnecessary control information used in the wired network, a process called header compression.

A Radio Resource Control (RRC) layer located on the lowest part of the third layer (L3) is defined only in the control plane. The RRC layer controls the transport channels and physical channels with respect to setting up, reconfiguring, and releasing or deregistering a Radio Bearer (RB). The RB denotes a service provided by the second layer (L2) for data transmission between the terminal 10 and the UTRAN 20. In general, the setting of the RB refers to a process of defining characteristics of a protocol layer and a channel required for providing a specific data service, and setting respective detailed parameters and operation methods.

The RRC state refers to whether or not there is a logical connection between the RRC of the terminal 10 and the RRC of the UTRAN 20. If a connection exists, the terminal 10 is said to be in the RRC connected state. If no connection exists, the terminal 10 is said to be in an idle state.

For the terminal 10 in the connected state, since the RRC connection exists, the UTRAN20 can determine in which cell a specific terminal specifically exists within the cell, for example, in which cell the RRC-connected terminal is located. Therefore, the terminal 10 can be effectively controlled.

In contrast, the UTRAN20 cannot determine the terminal 10 in the idle state. The above-described idle-state terminal 10 can be determined only by the core network 30 within a range larger than a cell, i.e., a specific area or a routing area. Therefore, the presence of the idle state terminal 10 is determined in a large area, and the idle state terminal must move or transition to the RRC connected state in order to receive mobile communication services such as voice or data.

When initially switched on by the user, the terminal 10 searches for a suitable cell and then remains in an idle state within the corresponding cell. When the idle state terminal 10 requires an RRC connection, it transitions to an RRC connected state through an RRC connection procedure in order to make an RRC connection with the RRC layer of the UTRAN 20.

There are many situations where the idle state terminal 10 needs to establish an RRC connection. The idle state terminal 10 must establish an RRC connection when uplink data transmission is required, for example, when a user attempts a call, or when a response message in reply to a paging message received from the UTRAN20 is transmitted. Another situation where an idle terminal 10 needs to establish an RRC connection is in order to receive a Multimedia Broadcast Multicast Service (MBMS).

The 3GPP system can provide a Multimedia Broadcast Multicast Service (MBMS), which is a new service in release 6. The 3GPP TSG SA (traffic and system perspective) defines a wide variety of network elements and their functionality for supporting the MBMS service requirements. The cell broadcast service provided by the conventional release 99 is limited to a service that plays text type short messages to a certain area. The MBMS service provided by release 6 is a further improved service which multicasts multimedia data to terminals (UEs) 10 that have subscribed to the corresponding service, in addition to broadcasting the multimedia data.

The MBMS service is a downward dedicated service that provides a streaming or background service to a plurality of terminals 10 by using a general or dedicated downward channel. The MBMS service is divided into a broadcast mode and a multicast mode.

The MBMS broadcast mode facilitates transmitting multimedia data to each user located in a broadcast area, and the MBMS multicast mode facilitates transmitting multimedia data to a specific user group located in a multicast area. The broadcast area represents an available area for broadcast services, and the multicast area represents an available area for multicast services.

A user who wishes to receive the MBMS service first receives a service announcement provided through a network. The service announcement provides the terminal 10 with a list of services to be provided and related information. In addition, the user must receive notification of the services provided by the network. The service announcement provides the terminal 10 with information related to the broadcast data to be transmitted.

If a user intends to receive a multicast mode MBMS service, the user subscribes to a multicast subscription group. A multicast subscription group is a group of users who have completed a subscription procedure. Once a user has subscribed to a multicast subscription group, the user can join the multicast group to receive a particular multicast service. A multicast group is a group of users that receive a particular multicast service. Joining a multicast group, also known as MBMS multicast activation, refers to incorporating a multicast group with users who wish to receive a particular multicast service. Thus, the user can receive specific multicast data by joining a multicast group (which is referred to as MBMS multicast activation).

The RNC23 transmits MBMS user data to the terminal 10 through the base station (node B)21 via the user plane of the UTRAN protocol. The UTRAN20 transfers MBMS user data by constructing and maintaining a Radio Access Bearer (RAB) for call communication between the terminal 10 and the core network 30. MBMS user data is transmitted only by the downlink. The MBMS radio bearer facilitates transfer of user data of a specific MBMS service, which is delivered by the core network 30, to the UTRAN20 only for a specific terminal 10.

The MBMS radio bearer is divided into a point-to-multipoint type and a point-to-point type. UTRAN20 selects one of two types of MBMS radio bearers to provide the MBMS service. In order to select one of the two MBMS radio bearers, the UTRAN20 should identify the number of users or terminals 10 of a specific MBMS service existing in one cell.

The UTRAN20 may count the number of terminals 10 to determine the type of MBMS radio bearer. When it provides information on the MBMS service via the MBMS common control channel or performs paging for a specific MBMS service, the UTRAN20 notifies the terminals 10 that it is counting the number of terminals.

When the terminal 10 receives a service notification indicating an MBMS service in which counting is being performed for a corresponding service, the terminal establishes a connection between the RRC entity of the terminal and the RRC entity of the UTRAN20 by transmitting an RRC connection request message to the UTRAN through an uplink common channel. The RRC connection request message informs the UTRAN20 that the terminal 10 desires to receive the corresponding MBMS service.

By counting the number of terminals 10 that have transmitted the RRC connection request message, the UTRAN20 can identify users who wish to receive a specific MBMS service in one cell. Then, the UTRAN20 establishes an MBMS radio bearer based on the count.

The UTRAN20 sets a point-to-point MBMS radio bearer if the number of users or terminals 10 present in the corresponding cell is less than a certain threshold. The UTRAN20 sets a point-to-multipoint MBMS radio bearer if the number of users or terminals 10 present in the corresponding cell is greater than or equal to a certain threshold. However, the existing paging method in which the UTRAN20 identifies the number of terminals 10 desiring to receive the MBMS service has many disadvantages.

When the UTRAN20 performs the MBMS service notification, a response message, such as an RRC response message, is transmitted from the terminal 10 that wishes to receive the MBMS service. The simultaneous concentration of the response messages on the uplink channel results in interference and increased load on the uplink. Since the UTRAN20 performs MBMS service notification on a plurality of terminals 10 using the MBMS common control channel and the corresponding terminals simultaneously notify the UTRAN that they want to receive the corresponding MBMS service via the uplink common channel, both interference and load increase on the uplink.

Because of the interference and the increase in load, an unnecessarily long time may be required for the terminal 10 to transmit the response message. Therefore, by the time the UTRAN20 should establish the MBMS radio bearer, some terminals may not be able to send the response message.

Once the number of response messages received by the UTRAN20 from the terminals 10 is greater than the threshold value for establishing the MBMS point-to-multipoint radio bearer, the UTRAN no longer needs to receive additional response messages because all requirements for selecting the radio bearer have been met. However, in the prior art, even if UTRAN20 has received more than a threshold number of response messages, UTRAN continues to receive response messages before the MBMS radio bearer is established. Therefore, uplink radio resources are undesirably wasted.

The RRC connection procedure is generally divided into three steps: the terminal 10 transmits an RRC connection request message to the UTRAN20, the UTRAN transmits an RRC connection setup message to the terminal, and the terminal transmits an RRC connection setup complete message to the UTRAN. These steps are illustrated in fig. 3.

Fig. 3 illustrates the prior art steps when the UTRAN20 accepts an RRC connection request of the terminal 10. When the idle-state terminal 10 desires to establish an RRC connection, the terminal first transmits an RRC connection request message to the UTRAN 20. The RRC connection request message may include an RRC establishment cause and an initial terminal identifier. This initial terminal identifier, or UE identity, is an identifier unique to a particular terminal 10 and allows identification of the terminal regardless of its location anywhere in the world.

In response to the RRC connection request, the UTRAN20 transmits an RRC connection setup message to the terminal 10. The RRC connection setup message may include an RNTI (radio network temporary identity) and radio bearer setup information transmitted together with the initial UE identity. The RNTI is a terminal identifier allocated to allow the UTRAN20 to recognize the connected terminal 10. The RNTI is used only when an RRC connection exists and is used only within the UTRAN 20.

In response to the RRC connection setup message, the terminal 10 establishes an RRC connection with the UTRAN20 and transmits an RRC connection setup complete message to the UTRAN 20. After the RRC connection has been established, the terminal 10 uses the RNTI instead of the initial UE identity when communicating with the UTRAN 20.

Because the initial UE identity is a unique identifier, frequent use may increase the chance of undesirable exposure. Therefore, this initial UE identity is only used briefly during the initial RRC connection procedure and, thereafter, the RNTI is used for security reasons.

However, the UTRAN20 may also reject the RRC connection request for various reasons, such as insufficient radio resources. Fig. 4 illustrates the prior art steps when the UTRAN20 rejects the RRC connection request of the terminal 10.

Upon receiving the RRC connection request from the terminal 10, the UTRAN20 transmits an RRC connection reject message if necessary to reject the RRC connection. The initial UE identity and the reject reason are included in an RRC connection reject message to inform the terminal 10 why the RRC connection was rejected. Upon receiving the RRC connection reject message, the terminal 10 returns to the idle state.

Fig. 5 illustrates a prior art method 100 for a terminal 10 to request an RRC connection. The method 100 includes: transmitting an RRC connection request message (S110), and running a timer (S120), determining whether an RRC connection setup message (S130) or an RRC connection reject message (S144) is received before the timer expires (S150), and repeating the process unless the RRC connection setup message or the RRC connection reject message is received, or determining that a threshold for transmitting an RRC connection request has been reached (S160).

Upon receiving the RRC connection request message from the terminal 10, the UTRAN20 grants the RRC connection request if radio resources are sufficient, and transmits an RRC connection setup message to the terminal. Otherwise, the UTRAN rejects the RRC connection request and sends an RRC connection reject message to the terminal 10.

Upon determining that the RRC connection setup message is received at step S130, the initial UE identity included in the RRC connection setup message is compared with the terminal' S own identity to determine whether the message is intended for the terminal 10. If the initial UE identity included in the RRC connection setup message is different from the identity of the terminal 10, the terminal discards the received message and determines whether an RRC connection reject message is received at step S144. If the initial UE identity included in the RRC connection setup message matches the identity of the terminal 10, the terminal establishes an RRC connection with the UTRAN20 and transitions to an RRC connected state.

Once the RRC connection is established with the UTRAN20, the RNTI allocated by the UTRAN20 is stored, and the RRC connection setup complete message is transmitted to the UTRAN20 at step S142. The RRC connection setup complete message includes capability information of the terminal 10. In step S170, the transmission of the additional RRC connection request message is terminated.

Upon determining that the RRC connection reject message is received at step S144, the initial UE identity included in the RRC connection reject message is compared with the terminal' S own identity to determine whether the message is intended for the terminal 10. If the initial UE identity included in the RRC connection reject message is different from the identity of the terminal 10, the terminal discards the received message and checks the status of the timer at step S150. If the initial UE identity included in the RRC connection reject message matches the identity of the terminal 10, the terminal transitions to the idle state at step S146 and terminates the RRC connection attempt at step S170.

Once it is determined that the timer has not expired at step S150, the terminal 10 continues to wait for reception of the RRC connection setup message or the RRC connection reject message. Once it is determined at step S150 that the timer has expired, it is determined at step S160 whether a threshold limit for transmitting an RRC connection request message has been reached.

If the threshold limit for sending the RRC connection request message has been reached, the terminal 10 terminates the RRC connection attempt at step S170. If the threshold limit for sending the RRC connection request message has not been reached, another RRC connection attempt is initiated at step S110, and the process is repeated.

Technical problem

In the prior art, when the UTRAN20 needs to transmit RRC connection reject messages to a plurality of terminals requesting RRC connection, radio resources are wasted because it takes an undesirably long time to transmit the RRC connection reject message. The best example of wasting radio resources described above occurs when providing multicast services.

The UTRAN20 performs a counting operation using the multicast service notification procedure to determine the total number of terminals 10 that desire to receive a particular multicast service within a particular cell. The counting operation is used to determine whether the radio bearer providing a particular multicast service should be point-to-multipoint or point-to-point. If the number of terminals present in the corresponding cell is less than a threshold, a point-to-point radio bearer is set. If the number of terminals is greater than or equal to the threshold, the point-to-multipoint radio bearer is set.

When the point-to-point radio bearer is set for a specific service, the terminals 10 that wish to receive the service are all in the RRC connected state. However, when the point-to-multipoint radio bearer is set for a specific service, all terminals 10 desiring to receive the service do not need to be in the RRC connected state because the RRC idle-state terminals can also receive the multicast service via the point-to-multipoint radio bearer.

For multicast services, the use of counting operations to select radio bearer types is essential to efficiently allocate radio resources. Therefore, the selection operation is performed before the multicast service is started, or periodically during the multicast service.

In order to count the number of terminals 10 on the UTRAN20, those terminals in the idle state immediately send an RRC connection request message to the UTRAN when receiving the service notification. When the UTRAN20 receives the RRC connection request message after the service notification, the number of terminals 10 desiring to receive a specific multicast service within the cell is counted to determine the type of radio bearer. Based on the radio resource condition, an RRC connection setup message is transmitted to some terminals 10 and an RRC connection reject message is transmitted to the remaining terminals so that some terminals in the RRC idle state can receive the corresponding service.

Since the multicast service is a service for a large number of terminals 10, the UTRAN20 receives RRC connection request messages from a large number of terminals almost simultaneously after service notification. The UTRAN20 typically rejects most of these RRC connection requests. Since each RRC connection reject message informs only one terminal 10 that its RRC connection request has been rejected, it takes a longer time and a large amount of radio resources to transmit the RRC connection reject message to all corresponding terminals, especially, in a multicast service in which a very large number of terminals are handled.

In addition, if the terminal 10 transmitting the RRC connection request message does not receive the RRC connection setup message or the RRC connection reject message within a certain time period, the terminal transmits the RRC connection request message again. Retransmission of the RRC connection request message wastes more radio resources because the UTRAN must receive each retransmitted message.

Accordingly, there is a need for an apparatus and method that facilitates notifying a plurality of terminals that their RRC connection request is rejected and should not be issued without sending an RRC connection reject message to each terminal, such that radio resources are conserved. The present invention addresses these and other needs.

Disclosure of Invention

Technical scheme

The present invention proposes an apparatus and method for establishing an RRC connection, which is an initial connection established between a terminal in an idle state and a UTRAN in a UMTS, through which a single connection message including a counted state is used by a network to inform a plurality of terminals that their connection requests should not be retransmitted.

To achieve these and other advantages and in accordance with the purpose of the present invention, as embodied and broadly described herein, the present invention is embodied in a mobile communication system and apparatus that facilitates RRC connection between a terminal and a UTRAN in UMTS in a manner of saving radio resources. In particular, an apparatus and method are provided that allow a UTRAN to inform multiple terminals that their connection requests should not be retransmitted because their previous RRC connection requests were rejected via a single message transmitted to the multiple terminals. Although the present invention is described herein with respect to UMTS developed by 3GPP, it is contemplated that the apparatus and method of the present invention may be applied whenever it is desired to inform a plurality of terminals in a mobile communication system that their connection requests should not be retransmitted because their previous requests for connection have been rejected.

In one aspect of the invention, a method for a terminal to wirelessly communicate with a network is provided. The method comprises the following steps: the method includes receiving a first connection message on a first channel indicating that a network connection with a terminal is required, transmitting a connection request to a network, waiting a determined time period to receive a connection response from the network on a second channel, receiving a second connection message on the first channel if a response message is not received within the determined time period, and determining whether to retransmit the connection request based on the second connection message.

The second connect message includes either a need for a connection indicator or no need for a connection indicator. Preferably, the second connection message is an RRC connection required message or an RRC connection not required message.

If the second connection message includes a required connection indicator, the connection request message is retransmitted. If the second connection message includes an unwanted connection indicator, the connection request message is not retransmitted.

Preferably, the first connection message is a message requiring RRC connection, the connection request is an RRC connection request message, and the response message is an RRC connection setup message. Preferably, the first connection message, the response message and the second connection message relate to a user service, such as an MBMS service.

In another aspect of the invention, a method for a terminal to wirelessly communicate with a network is provided. The method comprises the following steps: receiving a first connection message on a first channel indicating that a network connection with the terminal is required, initiating a network connection step relating to the user service by sending a connection request message to the network, waiting to receive a connection response from the network on a second channel, and terminating the network connection step upon the occurrence of internal and external events.

The internal event is preferably the expiration of an internal timer, which has a predetermined time limit. The external event is preferably the reception of a second connection message on the first channel comprising a message not requiring a connection indicator, preferably not requiring an RRC connection. The connection request message is not retransmitted once the network connection procedure is terminated.

In a preferred embodiment, the method further comprises: the connection request message is retransmitted upon expiration of the internal timer and occurrence of a different external event. The different external event is preferably the reception of a second connection message on the first channel comprising a need for connection indicator, preferably a need for RRC connection message.

Preferably, the first connection message is a message requiring RRC connection, the connection request is an RRC connection request message, and the response message is an RRC connection setup message. Preferably, the user service is an MBMS service.

It is contemplated that the first and second channels may be logical channels, transport channels, or physical channels. Preferably, the first channel is an MBMS control channel and the second channel is a common control channel.

In another aspect of the invention, a method for a network to wirelessly communicate with a plurality of terminals is provided. The method comprises the following steps: the method includes transmitting a first connection message indicating that network connection to a plurality of terminals subscribed to a service is required on a first channel, receiving a connection request message from at least one of the plurality of terminals, transmitting a second connection message including a connection setting indication to a specific terminal on a second channel, and transmitting a third connection message including either information that connection is required or information that connection is not required to the plurality of terminals on the first channel.

The third connection message includes information that a connection is required or information that a connection is not required is based on the number of received connection request messages. In a preferred embodiment, the third connection message includes information that a connection is required if the number of received connection request messages is less than a predetermined threshold, and includes information that a connection is not required if the number of received connection request messages is equal to and greater than the predetermined threshold.

It is contemplated that a plurality of second connection messages including a connection setup indication may be transmitted on the second channel. Each of the second connection messages is transmitted to a specific terminal and includes connection setting information, such as a terminal identifier, related to the specific terminal.

Preferably, the first connection message is a message requiring RRC connection, the connection request is an RRC connection request message, and the second connection message is an RRC connection setup message. Preferably, the user service is a point-to-multipoint service. Preferably, the third connection message is either a message requiring RRC connection or a message not requiring RRC connection and includes a service identifier for the service.

In another aspect of the invention, a terminal for wireless communication with a network is provided. The terminal comprises a transmitter, a display, a storage unit, a receiver and a processing unit.

The transmitter initiates a network connection procedure related to the user service by sending a connection request message to the network requesting a response message. The display conveys information to the user. The storage unit stores information related to the network connection and the user service. The receiver receives a first connection message including a required connection indicator and a second connection message including a required connection indicator or an unnecessary connection indicator from the network on a first channel, and receives a connection response message from the network on a second channel. The processing unit executes the method of the invention to determine whether the connection response message is received within a determined time period after sending the connection request message, and if the response message is not received, to evaluate the content of the second connection message in order to either retransmit the connection request message or to terminate the network connection procedure.

In another aspect of the invention, a network for wireless communication with a plurality of terminals is provided. The terminal includes a transmitter, a receiver, a storage unit, and a controller.

The transmitter transmits a first connection message indicating that a network connection related to a service is required to a plurality of terminals subscribed to the service on a first channel, transmits a second connection message including connection setting information to at least one specific terminal on a second channel, and transmits a third connection message including information that a connection is required or information that a connection is not required to the plurality of terminals on the first channel. The receiver receives a connection request message from at least one terminal. The storage unit stores information related to the network connection and the user service. The controller executes the method of the present invention to determine which of the plurality of terminals should set a communication connection, to transmit a second connection message to those terminals that determine to receive the communication connection, and to determine whether the third connection message should include information that a connection is required or information that a connection is not required based on the number of received connection request messages.

In one aspect of the present invention, there is provided a method of establishing a Radio Resource Control (RRC) connection between a terminal and a network providing a multimedia broadcast/multicast service (MBMS) to the terminal in a mobile communication system, the method including: transmitting an RRC connection request message to a network; receiving a counting state information message from the network on a second channel if the RRC connection setup message is not received from the network within a determined time period on the first channel; and determining whether the RRC connection request message should be retransmitted to the network based on the counting status information message.

In one embodiment, the counting state information message is an RRC message that is transmitted to all terminals within a cell that desires to receive the MBMS service.

In one embodiment, the counting status information message includes a counting end command indicating a counting procedure for the MBMS service that has been completed or a counting execution command indicating that the counting procedure for the MBMS service is in progress.

In one embodiment, the method further comprises: the RRC connection request message is retransmitted if the counting state information message includes a counting execution command, or the RRC connection request message is not retransmitted if the counting state information message includes a counting end command.

In one embodiment, the second channel is an MBMS control channel.

In one embodiment, the first channel is a common control channel.

In one embodiment, the counting status information message is a message transmitted to all terminals desiring to receive the MBMS service.

In one embodiment, the RRC connection request message is sent over a first channel.

In one embodiment, the method further comprises: after transmitting the RRC connection request message, a timer is set to calculate the determined time period.

In one embodiment, the method further comprises: switching from the first channel to the second channel after transmitting the RRC connection request message; and

after waiting a determined period of time, switching from the second channel to the first channel.

In one embodiment, the terminal is in an idle mode or idle state.

In one embodiment, the counting status information indicates whether the counting process has been completed.

In another aspect of the present invention, there is provided a method of establishing a Radio Resource Control (RRC) connection between at least one terminal and a network in a mobile communication system, wherein the network provides a multimedia broadcast/multicast service (MBMS) to the at least one terminal, the method including: receiving an RRC connection request message from at least one terminal; transmitting a counting state information message to at least one terminal so that the at least one terminal determines whether to retransmit the RRC connection request message based on the counting state information message when the at least one terminal does not receive the RRC connection setup message on the first channel; wherein the counting status information message is sent on the second channel.

In one embodiment, the counting status information message includes a counting end command indicating a counting procedure for an MBMS service that has been completed or a counting execution command indicating that the counting procedure for the MBMS service is in progress.

In one embodiment, the second channel is an MBMS control channel.

In one embodiment, the first channel is a common control channel.

In one embodiment, the counting status information message is a message transmitted to all terminals desiring to receive the MBMS service.

In one embodiment, the RRC connection request message is sent over a first channel.

In one embodiment, the at least one of all terminals is in an idle mode or idle state.

In one embodiment, the counting status information indicates whether the counting process has been completed.

Additional advantages, objects, and features of the invention will be set forth in part in the description which follows and in part will become apparent to those having ordinary skill in the art upon examination of the following or may be learned from practice of the invention. The objects and advantages of the invention may be realized and attained as particularly pointed out in the written description and claims hereof as well as the appended drawings.

It is to be understood that both the foregoing general description and the following detailed description of the present invention are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention. Features, elements, and aspects of the invention that are referenced by the same numerals in different figures represent the same equivalent or similar features, elements, or aspects in accordance with one or more embodiments.

Fig. 1 illustrates a network structure of a conventional 3GPP UMTS system.

Figure 2 illustrates an exemplary basic architecture of a conventional UMTS network.

Fig. 3 illustrates the steps of the prior art when the UTRAN accepts an RRC connection request of the terminal.

Fig. 4 illustrates the steps of the prior art when the UTRAN rejects the RRC connection request of the terminal.

Fig. 5 illustrates a related art method for processing an RRC connection setup message and an RRC connection reject message.

Fig. 6 illustrates the steps when the UTRAN accepts an RRC connection request of one terminal and rejects an RRC connection request of another terminal according to the method of the present invention.

Fig. 7 illustrates a method for processing an RRC connection setup message, a message requiring an RRC connection, or a message not requiring an RRC connection according to one embodiment of the present invention.

Fig. 8 illustrates a method for transmitting an RRC connection setup message, a message requiring an RRC connection, or a message not requiring an RRC connection according to an embodiment of the present invention.

Fig. 9 illustrates a terminal for processing an RRC connection setup message, a message requiring an RRC connection, and a message not requiring an RRC connection according to an embodiment of the present invention.

Fig. 10 illustrates a network for transmitting an RRC connection setup message, a message requiring an RRC connection, and a message not requiring an RRC connection according to one embodiment of the present invention.

Detailed Description

The present invention relates to an apparatus and method for establishing an RRC connection, which is an initial connection established between a terminal in an idle state and a UTRAN in a UMTS, by which a single connection message including a count state is used by a network to inform a plurality of terminals that their connection requests should not be retransmitted. Although the present invention has been illustrated with respect to a mobile communication system such as UMTS developed by 3GPP, and in particular with respect to RRC connection in connection with MBMS user services, it is contemplated that the apparatus and methods described herein may also be applied to communication systems operating under similar and/or different standards when it is desired to inform a plurality of terminals that their connection request is denied and that no connection denial message is sent to each terminal so that radio resources are conserved.

The present invention provides an apparatus and method for a terminal 410 to terminate a request RRC connection attempt by having a UTRAN520 broadcast a status information message of a count to all terminals in a cell desiring to receive a specific MBMS service. The counted status message is transmitted via the dedicated MBMS common channel instead of transmitting an RRC connection reject message to each terminal 410 whose connection request is rejected. Since the counted status information message is broadcast to all terminals 410 desiring to receive the specific MBMS service, only information indicating whether counting has been completed needs to be included in the counted status information message. Information identifying a specific terminal, such as an initial terminal identifier, need not be included in the counted status information message.

The present invention also provides a method by which the terminal 410 retransmits an RRC connection request upon receipt of a counted state information message if an RRC connection setup message is not received within a certain time period after transmitting the RRC connection request message. The terminal 410 determines whether to retransmit the RRC connection request message based on the content of the counted state information message.

The UTRAN520 transmits an RRC connection setup message via a first channel and transmits a status information message of the count via a second MBMS common channel dedicated to those terminals 410 that wish to receive a specific MBMS service. The counting status information message may include a counting end command indicating that counting for the specific MBMS service has been completed or a counting execution command indicating that counting for the specific MBMS service is in progress.

After sending the RRC connection request message, the terminals 410 run a timer and attempt to receive RRC connection setup messages transmitted to those terminals via the first channel. If the RRC connection setup message is not received before the timer expires, the terminal 410 switches to a second channel in order to receive the counted state information message of the MBMS service.

If the counted state information message includes a counting end command, the terminal 410 determines that the counting procedure for the MBMS service has ended and does not retransmit the RRC connection request message. If the counted state information message includes a counting execution command, the terminal 410 determines to continue the counting procedure of the MBMS service and retransmits the RRC connection request message.

Fig. 6 illustrates steps according to the present invention when the UTRAN520 grants an RRC connection request of a terminal 410 desiring to receive a specific MBMS service in a specific cell and rejects an RRC connection request of another terminal desiring to receive the specific MBMS service in the specific cell. Upon receiving a message requiring an RRC connection from the UTRAN520 on the first channel, the terminals 410 in idle state, such as UE 1 and UE 2, that wish to establish an RRC connection each send an RRC connection request message to the UTRAN.

The message requiring RRC connection may include a service ID related to the specific MBMS service. Each RRC connection request message may include an RRC establishment cause and an initial terminal identifier. This initial terminal identifier, or UE identity, is an identifier unique to a particular terminal 410 and allows the particular terminal to be identified regardless of its location anywhere in the world. Preferably, the message requiring RRC connection is transmitted on an MBMS Control Channel (MCCH) and the RRC connection request message is transmitted on a Common Control Channel (CCCH).

Upon transmitting their respective RRC connection request messages on the second channel, preferably the Common Control Channel (CCCH), UE 1 and UE 2 each trigger an internal timer and wait for an RRC connection setup message. As illustrated in fig. 6, the UTRAN520 determines that UE 2 should establish a network connection and UE 1 should not establish a network connection. The UTRAN520 transmits the RRC connection setup message to the UE 2 on the second channel, but does not transmit the RRC connection setup message to the UE 1.

The RRC connection setup message transmitted to the UE 2 may include an RNTI (radio network temporary identity) and radio bearer setup information transmitted together with the initial UE identity. The RNTI is a terminal identifier allocated to allow the UTRAN520 to recognize the connected state terminal 410. The RNTI is used only when an RRC connection exists and is used only within the UTRAN 520.

In response to the RRC connection setup message, UE 2 establishes an RRC connection with UTRAN520 and transmits an RRC connection setup complete message to the UTRAN. After the RRC connection has been established, UE 2 is in an RRC connected state when communicating with UTRAN520 and replaces the initial UE identity with the RNTI.

On the other hand, upon expiration of its internal timer, UE 1 switches to the first channel and receives a message that the RRC connection is not required. The reception of the message requiring no RRC connection indicates that the counting operation for the specific MBMS service has been completed, which means that the RRC connection request message from the UE 1 is rejected. The UE 1 terminates the RRC connection procedure and does not retransmit the RRC connection request message.

Although fig. 6 illustrates the procedure for only two terminals 410, the procedure is applicable to any number of terminals desiring to receive a specific MBMS service when the UTRAN520 determines that some terminals should establish an RRC connection and other terminals should not. The terminal 410, which determines to establish the RRC connection, will receive the RRC connection setup message on the second channel and enter the RRC connected state. The terminal that determines not to establish the RRC connection will receive a message on the first channel that does not require the RRC connection and return to the idle state. Further, it is expected that if the internal timer of the terminal 410 expires before receiving the RRC connection setup message, but the counting operation is still ongoing, the terminal will receive a message requiring RRC connection on the first channel and retransmit the RRC connection request message.

Fig. 7 illustrates a method 200 according to an embodiment of the present invention, the method 200 initiating an RRC connection procedure in a terminal 410, waiting for an RRC connection setup message, and determining to retransmit the RRC connection request message or terminate the RRC connection procedure once the RRC connection setup message is not received after a predetermined period of time. The method 200 comprises: receiving a message requiring an RRC connection on a first channel (S202), initiating a network connection procedure by transmitting an RRC connection request message (S210), reading a second channel (S225), and establishing an RRC connection if the RRC connection setup message is received (S230) (S242), or receiving a message requiring an RRC connection or a message not requiring an RRC connection on the first channel if an internal timer expires (S244) before the RRC connection setup message is received (S244) to determine (S260) to enter an idle state (S267) and terminate the network connection procedure (S270), or retransmitting the RRC connection request message (S210).

In step S202, an RRC connection message related to a user service to which the terminal 410 subscribes is received from the UTRAN520 on a first channel. Then, the terminal 410 transmits an RRC connection request message to the UTRAN520 at step S210. The RRC connection request message requests that an RRC connection setup message be sent on the second channel.

The terminal 410 initializes an internal timer and monitors a second channel for an RRC connection setup message from the UTRAN520 at step S225. In step S230, the terminal checks whether an RRC connection setup message is received.

If the RRC connection setup message is received, a connection to the network is established and an RRC connection setup complete message is transmitted to the network at step S242. Further, in step S270, retransmission of the RRC connection request message is suspended.

If the RRC connection setup message is not received, it determines whether the internal timer has expired at step S244. If the timer has not expired, the terminal 410 continues to check for receipt of the RRC connection setup message in step 230. If the timer has expired, the terminal 410 monitors the first channel at step S250.

In step S250, the terminal 410 receives a message requiring RRC connection or a message not requiring RRC connection on the first channel. If a message requiring RRC connection is received, the counting procedure is still performed, and the terminal retransmits the RRC connection request message at step S210. If a message that the RRC connection is not required is received, the counting procedure is ended and the RRC connection request of the terminal is rejected. The terminal 410 enters the idle state and the network connection procedure is abandoned at step S267, and further retransmission of the RRC connection request message is aborted at step S270.

Fig. 8 illustrates a method 300 for processing an RRC connection request message and transmitting an RRC connection setup message and a message requiring an RRC connection, or a message not requiring an RRC connection, in a network according to one embodiment of the invention. The method 300 includes receiving an RRC connection request message (S310), and determining whether a threshold for processing the RRC connection request message has been satisfied (S320). If the RRC connection request threshold is not satisfied, an RRC connection setup message is transmitted to the terminal that transmitted the RRC connection request message (S330), and a message requiring RRC connection is transmitted (S340). If the RRC connection request threshold has been satisfied, a message that the RRC connection is not required is transmitted (S350).

It should be noted that the order of the method steps illustrated in fig. 7 and 8 is merely exemplary and may be varied without departing from the intent of the present invention. Furthermore, the methods illustrated in fig. 7 and 8 may be performed by suitable software and/or hardware in the UTRAN520 and in each terminal 410.

Fig. 9 illustrates a block diagram of a terminal 410 according to a preferred embodiment of the present invention. The terminal 410 includes a processor or digital signal processor 412, an RF module 435, a power management module 405, an antenna 440, a battery 455, a display 415, a keypad 420, a memory 430, a SIM card 425 (which is optional), a speaker 445, and a microphone 450.

The user enters command information, such as a telephone number, for example, by pressing keys of the keypad 420, or by voice activation using the microphone 450. The processor 412 receives and processes the command information to perform the appropriate function, such as dialing a telephone number. The operational data may be retrieved from the Subscriber Identity Module (SIM) card 425 or the memory module 430 to perform a function. In addition, the processor 412 may display command and operational information on the display 415 for reference and convenience by the user. Further, the processor 412 is adapted to perform the method 200 illustrated in fig. 7.

The processor 412 issues command information to the RF module 435 to initiate communication, for example, sending a radio signal including voice communication data, or sending an RRC connection request message as described herein. The RF module 435 includes a receiver and a transmitter to receive and transmit wireless signals. The antenna 440 facilitates the transmission and reception of wireless signals. Upon receiving a wireless signal from the network described herein, such as an RRC connection setup message, a message requiring an RRC connection, or a message not requiring an RRC connection, the RF module 435 may forward and convert the signal to a baseband frequency for processing by the processor 412. For example, if the wireless signal is an incoming telephone call, the processed signal may also be converted to audible or readable information that is output via speaker 445.

Fig. 10 illustrates a block diagram of a UTRAN520 according to a preferred embodiment of the present invention. The UTRAN520 includes one or more Radio Network Subsystems (RNSs) 525. Each RNS 525 includes a Radio Network Controller (RNC)523 and a plurality of node bs (base stations) 521 managed by the RNC. The RNC523 handles the allocation and management of radio resources and functions as an access point with respect to the core network 30. Further, the RNC523 is adapted to perform the method 300 illustrated in fig. 8.

The node B521 receives information transmitted by the physical layer of the terminal 410 via an uplink and transmits data to the terminal via a downlink. The node B521 functions as an access point or a transmitter and a receiver of the UTRAN520 for the terminal 410.

In the prior art, when the UTRAN20 rejects the RRC connection request transmitted from a certain terminal 10, a reject message must be transmitted to each terminal from which the RRC connection request is rejected. Undesirably long time is required to send multiple reject messages, which wastes downlink radio resources. Uplink radio resources may also be wasted because some terminals 10 may retransmit their RRC connection request if they do not receive any response from the UTRAN20 within the allowed time.

The present invention facilitates transmission of a single end-of-count message, e.g., a message that does not require RRC connection, to reject RRC connection requests of multiple terminals 410, thereby minimizing waste of radio resources and providing a quick response to those terminals that sent the requests. It will be appreciated that the present invention is particularly beneficial when multiple access communication services are provided to a large number of terminals 410.

It will be readily apparent to those skilled in the art that the preferred embodiment of the present invention may be readily implemented using, for example, the processor 412 or other data or digital processing device, either alone or in combination with external support logic.

Although the present invention is described in the context of mobile communications, the present invention may also be used in any wireless communication system using mobile devices, such as PDAs and portable computers equipped with wireless communication capabilities. Furthermore, certain terms used to describe the present invention should not be limited to certain types of wireless communication systems, such as UMTS, within the scope of the present invention. The present invention is also applicable to other wireless communication systems using different air interfaces and/or physical layers, e.g., TDMA, CDMA, FDMA, WCDMA, etc.

The preferred embodiments may be implemented as a method, apparatus or article of manufacture using standard programming and/or construction techniques to produce software, firmware, hardware, or any combination thereof. The term "article of manufacture" as used herein refers to code or logic circuitry implemented in hardware logic (e.g., an integrated circuit chip, Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), etc.) or a computer readable medium (e.g., magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, firmware, programmable logic, etc.) in which the code is accessed and executed by a processor Wireless transmission media, the propagation of signals through space, radio waves, infrared signals, and the like. Of course, those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope of the present invention, and that the article of manufacture may comprise any information bearing medium known in the art.

The logic embodiments illustrated in the figures describe specific operations as occurring in a particular order. In alternative embodiments, certain of the logic operations may be performed in a different order, modified or removed and still implement preferred embodiments of the present invention. Moreover, steps may be added to the above described logic and still conform to embodiments of the invention.

The foregoing embodiments and advantages are merely exemplary and are not to be construed as limiting the present invention. The present teachings can be readily applied to other types of apparatuses. The description of the present invention is intended to be illustrative, and not to limit the scope of the claims. Many alternatives, modifications, and variations will be apparent to those skilled in the art. In those claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents, but also equivalent structures.

Claims (20)

1. A method of establishing a Radio Resource Control (RRC) connection between a terminal and a network providing a multimedia broadcast/multicast service (MBMS) to the terminal in a mobile communication system, the method comprising:

transmitting an RRC connection request message to a network;

receiving a counting state information message from the network on a second channel if the RRC connection setup message is not received from the network within a determined time period on the first channel; and

determining whether the RRC connection request message should be retransmitted to the network based on the counting status information message.

2. The method of claim 1, wherein the counting state information message is an RRC message transmitted to all terminals within a cell desiring to receive the MBMS service.

3. The method of claim 1, wherein the counting status information message comprises a counting end command indicating that a counting procedure of the MBMS service has been completed, or a counting execution command indicating that the counting procedure of the MBMS service is ongoing.

4. The method of claim 3, further comprising:

the RRC connection request message is retransmitted if the counting state information message includes a counting execution command, or the RRC connection request message is not retransmitted if the counting state information message includes a counting end command.

5. The method of claim 1, wherein the second channel is an MBMS control channel.

6. The method of claim 1, wherein the first channel is a common control channel.

7. The method of claim 1, wherein the counting status information message is a message transmitted to all terminals desiring to receive the MBMS service.

8. The method of claim 1, wherein the RRC connection request message is sent over the first channel.

9. The method of claim 1, further comprising:

after transmitting the RRC connection request message, a timer is set to calculate the determined time period.

10. The method of claim 1, further comprising the step of:

switching from the first channel to the second channel after transmitting an RRC connection request message; and

switching from the second channel to the first channel after waiting a determined period of time.

11. The method of claim 1, wherein the terminal is in an idle mode or an idle state.

12. The method of claim 1, wherein the counting status information indicates whether a counting process has been completed.

13. A method of establishing a Radio Resource Control (RRC) connection between at least one terminal and a network providing a multimedia broadcast/multicast service (MBMS) to the at least one terminal in a mobile communication system, the method comprising:

receiving an RRC connection request message from at least one terminal;

transmitting a counting state information message to at least one terminal so that the at least one terminal determines whether to retransmit the RRC connection request message based on the counting state information message when the at least one terminal does not receive the RRC connection setup message on the first channel;

wherein the counting status information message is transmitted on a second channel.

14. The method of claim 13, wherein the counting status information message comprises a counting end command indicating that a counting procedure of the MBMS service has been completed, or a counting execution command indicating that the counting procedure of the MBMS service is in progress.

15. The method of claim 13, wherein the second channel is an MBMS control channel.

16. The method of claim 13, wherein the first channel is a common control channel.

17. The method of claim 13, wherein the counting status information message is a message transmitted to all terminals desiring to receive the MBMS service.

18. The method of claim 13, wherein the RRC connection request message is transmitted over the first channel.

19. The method of claim 13, wherein the at least one of all terminals is in an idle mode or idle state.

20. The method of claim 13, wherein the counting status information indicates whether a counting process has been completed.