Sign In to Follow Application
View All Documents & Correspondence

Bearer Singnalling Management

Abstract: A method and system of bearer management signalling in a communication network comprising of transporting bearer resource request of both the UE and RN via DeNB to EPC as a signalling message over uplink channel referred to as "Union of Resource Request (UR Request)" message. The response message comprising of bearer resource response from one of the managing entity or plurality of managing entities of EPC are transported as a signalling message to Evolved Packet Edge (EPE) via DeNB over the downlink channel referred to as "Union of Admission Response (UA Response)". This manages bearer setup signalling as a single loop, by transportation of "UR Request" signalling message and receiving one "UA Response" signalling message over uplink and downlink channels respectively. EPE is a conglomeration of network nodes comprising of UEs, RNs and all other network nodes that communicate over EPC via DeNB. Network nodes in the EPE may establish connectivity external to EPC like Internet or PSTN (Public Switch Telephone Network).

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
20 December 2011
Publication Number
28/2012
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
Parent Application
Patent Number
Legal Status
Grant Date
2022-06-23
Renewal Date

Applicants

TEJAS NETWORKS LIMITED
TEJAS NETWORKS LIMITED 2ND FLOOR. GNR TECH PARK, 46/4, GARVEBHAVI PALYA, KUDLU GATE, HOSUR MAIN ROAD, BANGALORE-560068 KARNATKA, INDIA

Inventors

1. ROHIT KUMAR
VILLAGE & POST-PARWALPUR, DISTT.-NALANDA, BIHAR 803114
2. SANIL R.C
SAKETHAM, C.S. STREET, PO. POOKODE, VIA. PATHAYAKKUNNU, KANNUR DIST, KERALA 670691
3. VINOD KUMAR M
B-207, JANHAVI MEADOWS, BEGUR KOPPA ROAD, YELLANAHALLI, BANGALORE, 560068 KARNATKA

Specification

Field of the Invention

The present disclosure relates to bearer management in a wireless communication network. In particular, the invention relates to transport of signalling messages on the interface between a relay node and another node in a mobile communication network.

Background

Wireless network technologies are widely deployed to provide various communication contents such as voice, video, packet data, messaging, broadcast, etc., which provide multiple-access systems capable of supporting multiple users by sharing the available system resources. In order to provide better qualities of service and wider communication ranges between wireless nodes, the concept of relay station has been introduced in network systems. The purpose of deploying relay station in network system is to extend the serving coverage of base station; hence, user equipment (UE) which is not within the communication coverage of base station can access the services provided by relay station as well via base station.

Wireless network architecture as defined by 3GPP introduces wireless relay node (RN) entity to extend the coverage of base station (eNB). A long term evolution-advanced (LTE-A) system, as its name implies, is an evolution of the LTE system, considering relaying for cost-effective throughput enhancement and coverage extension. For example, a relay can be deployed at the cell edge where the eNB is unable to provide required radio quality/throughput for the UEs or at certain location where radio signals of the eNB cannot cover.

The RN forms an independent physical cell. From a user equipment (UE) perspective, the RN is seen as a usual base station. The RN is connected via a wireless link to the base station. The relay node architecture deployment foresees that a RN emulates a base station for the UE, which means that the UE would see the RN as a usual base station. From the network side, the RN is seen as a usual UE by the base station. The base station, to which the RN is connected, is called Donor-eNB (DeNB) and operates as a usual base station. The deployment of RN in the 3GPP network architecture is described in 3GPP Technical Specification 36.806; "Relay architectures for E-UTRA (LTE-Advanced)".

In order for the user equipment to receive a service from the network, it needs to establish connectivity via base station, by initiating Non-Access Stratum (NAS) signalling messages with network nodes like Mobility Management Entity (MME) serving the UE. Consequential signalling messages are exchanged between network nodes to allocate bearer resources for UE and RN to service the UE request. The above bearer management procedure can be initiated by UE or the Evolved Packet Core (EPC in terms of 3GPP LTE) or simply the communication network. Similar procedures are followed for managing existing bearers. The managing functions include creating new entry, updating and deleting.

Thus, whenever a UE bearer is created or modified, the RN bearer modify or create procedures may be initiated by the RN. This increases the exchange of messages separately for the UE and for the RN to modify/create a new bearer. Thus additional messages may be exchanged by the RN each time a bearer is created/modified for the UE, leading to delayed access service and as well as backhaul bandwidth is wasted or underutilized. Therefore, there is a need for a bearer management to optimize radio and backhaul resources by effectively setting-up the bearers.

Summary of the invention

The summary represents the simplified condensed version of the claimed subject matter and it is not an extensive disclosure of the claimed subject matter. The summary neither identifies key or critical elements nor delineates the scope of the claimed subject matter.
The summary presents the simplified form of the claimed subject matter and acts as a prelude to the detailed description that is given below.

The present invention and its embodiments are made to provide for a feasible solution for facilitating bearer management in a communication network optimizing exchange of signalling communication in managing bearers for UE.

An aspect of the invention provides for a method of managing bearer signalling in a communication network, by transporting 'Union of Resource Request' (UR Request) signalling message from Evolved Packet Edge (EPE) entities to managing entities of EPE via DeNB and receiving 'Union of Admission Response' (UA Response) signalling message for the transported UR Request from at least one of the said managing entity, wherein the said management entity serves/manages all the entities in the EPE. EPE is a conglomeration of network nodes comprising of UEs, RNs and all other network nodes that communicate over EPC via DeNB. Network nodes in the EPE may establish connectivity external to EPC like Internet or PSTN (Public Switch Telephone Network).
Another aspect relates to receiving 'Union of Admission Response' (UA Response) signalling message for the transported UR Request from plurality of managing entities, wherein at least one of the said managing entities are not serving/managing the same entities in the EPE. Another aspect relates to transmitting from the user equipment (UE) coupled to a relay node (RN) or relay nodes, bearer request, either single or multiple bearers within a single NAS message to a mobility management entity serving the user equipment (MME_UE). The bearer request is received at the relay node (RN) as a UE NAS Message which is added with the relay node identity RNJD, (referred to as RN_TAG) and forwarded to MMEJJE by insertion of RN_TAG message at any one of the protocol layers preferably over any one of the S1-AP, SCTP, NAS protocol layers.
The RN_TAG message is processed by the mobility management entity serving the user equipment (MMEJJE). MMEJJE grants the bearer request of the UE and then a 'RR Request message for Relay node is generated by the Mobility Management Entity serving the user equipment (MMEJJE) based on the RNJD stored, to be sent to the mobility management entity serving the relay node (MME_RN). Upon receiving the RR Request message MME_RN processes the bearer request of RN and if MME_RN grants the bearer request of RN, a RR RESPONSE-POSITIVE ACK message, is generated and forwarded to MMEJJE. In response MMEJJE generates UA RESPONE ACCEPT message and forwards to RN.

Another aspect relates to generating UA RESPONSE REJECT message and forwarding to RN if the MME_RN does not grant the RN bearer request.' Another aspect relates to generating S1-AP UA REJECT message for UE, if the MMEJJE upon receiving the RN_TAG message from RN does not grant UE bearer request. All the above responses are referred to as Union of Admission responses which are available to the RN. The RN receives one amongst the Union of Admission responses from MMEJJE. Another aspect relates to systems facilitating the above method of managing bearers each comprising of at least a receiver, for receiving the said messages, processors for executing the functions, transmitter for transmitting messages, a memory for storing information and retaining instructions for executing functions associated with the above methods.

Another aspect relates to respective network nodes like RN, MMEJJE, MME_RN facilitating the above method of managing bearers each comprising of at least a receiver, for receiving the said messages, processors for executing the functions, transmitter for transmitting messages, a memory for storing information and retaining instructions for executing functions associated with the above methods.

Other aspects, advantages, and salient features of the invention will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses exemplary embodiments of the invention.

Description of the Drawings

The features, advantages and other aspects of the embodiments of the present invention will be obvious to any person skilled in the art to appreciate the invention when read with the following description taken in conjunction with the accompanying drawings.

Figure 1 illustrates a relay enhanced communication network as specified in 3GPP LTE network architecture, where the subject matter of the embodiments of the invention is deployed.

Figure 2 is an illustrative representation of multiple base stations (DeNB), as specified in 3GPP network architecture, being served by one or more of MMEs and SGWs.

Figure 3 is an illustration of existing radio bearer establishment procedure for user equipments (UE) and relay nodes (RN) as specified in 3GPP LTE (A) network architectures.

Figure 4 shows the network nodes conglomeration between two network entities in accordance with the principles of the invention.

Figure 5 represents 'UR Request' message signalling in the uplink from Evolved Packet Edge to Evolved Packet Core via DeNB in accordance with the embodiments of the invention.

Figure 6 depicts the 'Union of Admission Response (UA Response)' that are available to RN in accordance with the embodiments of the invention.

Figure 7 shows a detailed method of relay node identity tagging (RN_TAG) in any one of the control plane protocol layers.

Figure 8 represents bearer management signalling loop in accordance with various aspects of the invention.

Figure 9 is the first sequence flowchart of the methodology performed by the relay node in accordance with the embodiments of the invention.

Figure 10 is the second sequence flowchart of the methodology performed by the mobility management entity serving the UE (MMEJJE) in accordance with the embodiments of the invention.

Figure 11 is the third sequence flowchart of the methodology performed by the mobility management entity serving the RN (MME_RN) in accordance with the embodiments of the invention.

Figure 12 is the fourth sequence flowchart of the methodology performed by the mobility management entity serving the UE (MME_UE) in accordance with the embodiments of the invention.

Figure 13 illustrates a system diagram of various components of devices within a relay node, in accordance with the embodiments of the invention.

Figure 14 illustrates a system diagram of various components of devices within the MME _UE, in accordance with the embodiments of the invention.

Figure 15 illustrates a system diagram of various components of devices within the MME_RN, in accordance with the embodiments of the invention.

The figures are not drawn to scale and are illustrated for simplicity and clarity to help understand the various embodiments of the present invention. Throughout the drawings it should be noted that like reference numbers are used to depict the same or similar elements, features and structures.

Detailed Description

The following descriptions with reference to the accompanying drawings are provided to assist in a comprehensive understanding of exemplary embodiments of the invention as defined by the claims and their equivalents. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention.

The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the invention. Accordingly, it should be apparent to those skilled in the art that the following description of exemplary embodiments of the present invention are provided for illustration purpose only and not for the purpose of limiting the invention as defined by the appended claims and their equivalents.

In the figures 1 to 15 like reference numerals are used to refer to like elements throughout. In the figures certain embodiments are shown in block diagrams in order to facilitate describing those embodiments. The terms, component, module, system, and the like are intended to refer to a computer-related entity, either hardware, software, a combination of hardware and software. For eg., a component may be, but not limited to being, a process running on a processor, a processor, an integrated circuit, or a computer.
Both an application running on a computing device and the computing device can be a component. A component may be localized on one computer and/or distributed between two or more computers. The components may communicate by way of local and/or remote processes.

Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged systems. The terms used to describe various embodiments are exemplary. It should be understood that these are provided to merely aid the understanding of the description, and that their use and definitions in no way limit the scope of the invention.

Any term specifically reciting some of the present invention's characteristic, parameter, or value need not be achieved exactly, but that deviations or variations, including tolerances, measurement error, measurement accuracy limitations and other factors known to those of skilled in the art, may occur in amounts that do not preclude the effect the present invention was intended to provide.

The present invention and its embodiments are mainly described in relation to 3GPP specifications and standards (LTE-Advanced) for applicability of certain exemplary embodiments. The terminology used is therefore related thereto. Such terminology is used in the context of describing the embodiments of the invention and it does not limit the invention in any way. Any other network architecture or system deployment, etc., may also be utilized as long as it is compliant with the features described herein.

In particular, embodiments of the present invention may be applicable in any relay-enhanced (cellular) system with a need for signalling optimization. Embodiments of the present invention may be applicable for/in any kind of modern and future communication network including any mobile/wireless communication networks/systems.

Example embodiments to be described below are not intended to limit the present invention to any specific example, embodiment, environment, applications, or particular implementations described in these example embodiments. It should be appreciated that, in the following example embodiments and the attached drawings are illustrated for the ease of understanding, but not to limit the actual scale.

The following paragraphs will describe various embodiments of the invention. For exemplary purposes only, most of the embodiments are outlined according to the LTE-Advanced mobile communication system with the solution to the problem discussed in the background. It should be noted that the invention may be advantageously used in connection with the communication system described above, but the invention is not limited to its use in this particular exemplary communication network. The explanations given below are intended to better understand specific exemplary embodiments described herein and should not be understood as limiting the invention to the specific implementations of processes and functions in a mobile communication network. The improvements/solutions proposed herein may be readily applied in architectures/systems having relevance to relay architectures. Some embodiments of the invention may also make use of standard and improved procedures of these architectures/systems.
The techniques described herein may be used for various wireless communication networks such as CDMA networks, CDMA implementing radio technology such as UTRA, TDMA networks, TDMA implementing radio technology such as GSM, FDMA networks, OFDMA networks, OFDDA implementing radio technology such as Evolved URTA (E-UTRA), SC-FDMA networks.

User equipment (UE) used in the following description denotes various terminologies used like an access terminal, AT, wireless communication device, terminal, wireless handset, computer or wireless module, wireless module for use with a computer, personal digital assistant (PDA), tablet computer or device.

Figure 1 represents an overall architecture of a network with a relay node (RN). A relay node 10 has a base station (DeNB) 30 and a terminal side called as user equipment (UE) 20. Towards UE 20 the RN 10 behaves as a conventional eNB using the access link 15 (Uu interface) and the UE 20 is not aware of whether it is communicating with a rely node 10 or a base station 30. Relay nodes are therefore transparent for the UEs. Towards base stations relay nodes initially operate as a UE using the radio interface to connect to the base station. Once connection is established and the relay node is configured, the relay uses a subset of the UE functionality for communication on the backhaul link 25 (Un interface). In relay architecture as shown in the above figure, donor eNB 30 acts as a proxy between the core network 100 and the relay node 10. From the relay perspective, it appears as if RN 10 is directly connected to the core network 100 as the donor eNB appears as a mobility management entity (MME) 101 for the S1 interface and an eNB for X2 interface towards the relay node 10. From the perspective of core network 100, the relay node 10 appears as it belongs to the donor eNB.

Core network 100 and also other blocks (106, 107), show the relationship between them. The above diagram shows signalling interfaces. Interfaces like S1, S2 supports both user plane and control plane signalling, whereas interfaces like S6, S7 support only control plane signalling. The IMS (IP Multimedia Subsystem) 105 located on top of the blocks provide access to both private IP network 107 and PSTN (Public Switched Telephone Network) 106 via Media Gateway network entities. The HSS (Home Subscriber Server) 108 manages user subscription information and provides services to all Core Network (CN) 100 blocks of 3G and evolved 3G architecture. The MME 101 is in charge of all the control plane functions related to subscriber and session management. Its responsibility includes connection/release of bearers to a terminal, handling of IDLE to ACTIVE transitions, and handling of security keys. The functionality operating between the UE and the Core Network is referred to as Non-Access Stratum (NAS), whereas Access Stratum (AS) handles functionality operating between the terminal and the radio access network. It supports security procedures, terminal-to-network session handling, and Idle terminal location management. The MME 101 is linked through the S6 interface to the HSS and is linked through the S1 interface to the donor eNB. The Serving GW 102 is the termination point of the packet data interface towards donor eNB and UE through RN (E-UTRAN 100a). When UEs move across eNB in E-UTRAN 100a, Serving GW 102 serves as a local mobility anchor, meaning that packets are routed through this point for intra E-UTRAN mobility and mobility with other 3GPP technologies like 2G/GSM and 3G/UMTS. The Packet Data Network Gateway (PDN GW) 103 is similar to the Serving GW 102. The PDN GW is the termination point of the packet data interface towards Packet Data Network and also supports policy enforcement features as well as packet filtering (like deep packet inspection for virus signature detection) and evolved charging support (like per URL charging). Policy and Charging Rules Function (PCRF) 104 enforces policy features (which apply operator-defined rules for resource allocation and usage.

The UEs are connected to the RN by means of an Uu interface 15 and the RN to the Donor eNB by means of Un interface 25. The eNodeBs are normally interconnected with each other by means of the X2-lnterface, and to the Core Network by means of the S1 interface, more specifically to the MME (Mobility Management Entity) via the S1- MME, and to the Serving Gateway (S-GW) by means of the S1-U interface. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNode Bs.

When the network eg., MME 101 has no valid location or routing information for the UE 20, the UE 20 cannot be reached. This is more likely when the UE 20 is in a state of switched off, or out of coverage area. 3GPP defines this state as a de-registered state and this could also happen when the UE is in non-3GPP access. When the UE 20 is attached to the network eg., MME 101 it can receive Core Network 100 services. This state is defined by 3GPP as registered state. In this registered state the UE 20 can be in two different connection management states like RRCJDLE state and RRC_CONNECTED state. When no data is being transmitted and the radio resources are released, the UE has a valid IP configuration. In such idle state there is no Non-Access Stratum (NAS) signalling connection between the UE and the network, e.g., MME 101. Also during the idle state there is no S1 connection between the eNB and the Serving Gateway. In the RRC_CONNECTED state, there is an active connection between the UE 20 and donor eNB 30, which implies a communication context being stored within the donor eNB 30 for this UE 20. Both sides can exchange user data and or signalling messages over logical channels.

From the wireless network perspective, protocol structure for the User and Control planes correspond to user data transmission and signalling transmission. Control plane corresponds to the information flows actually considered as signalling by E-UTRAN 100a and Core Network 100. This includes all the RRC (Radio Resource Control) E-UTRAN signalling (supporting functions such as Radio Bearer management, radio mobility, user paging) and NAS (Non Access Stratum) signalling.

On the radio interface, the Control plane uses the Control plane protocol stack namely PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control) and PHY (Physical) stack to transport both RRC and Core Network NAS signalling. The above protocol stack layers support the same functions for both the User and Control Planes. The NAS signalling stops at MME 101 level because the top-level protocols terminate in the MME.

When a Non-Access Stratum (NAS) signalling connection needs to be established between the UE 20 and the MME 101 routed via relay node 10, the UE 20 and the MME 101 shall enter the connected state. The NAS protocol/signalling occurs between the UE 20 and the MME 101 via relay node 10, thus supporting mobility management functionality as well as the user plane bearer activation, modification and deactivation.

It should be noted that donor eNB is in fact connected to more than one MME or Serving GW node. In the figure 2, MMEs 101 and Serving GWs 102 are seen connected to more than one donor eNBs 30. These donor eNBs form a pool area 201 and 202 such that a pool area can be served by one or several MME and/or Serving GW. Pool areas can also overlap (Pool area 203). A given MME or Serving GW node may serve one or several pool areas. The connectivity of the relay node and the UE communicating via relay node, is managed by the network eg., MME. The MME manages a pool referred to as201, 202 or 203 as shown in figure 2. Based on initial NAS signalling, MMEs in the pool analyzes the request and determines which MME should manage the radio resources for the respective relay node or the UE communicating via relay node. This communication message essentially comprising of bearer request acknowledgement, indicates the uplink channel through which the UE is to communicate for establishing radio bearers. For the sake of simplicity MME 101a managing the UE 20 and the MME 101b managing the RN 10 is indicated as MMEJJE and MME_RN respectively, hereinafter. Similarly the Serving GW 102 managing the UE 20 and the Serving GW 102 managing the RN 10 is indicated as SGW/PGW_ UE and SGW/PGW_RN respectively, hereinafter.

Figure 3 shows the signalling message for bearer initiation procedure existing in 3GPP LTE specification. UE 20 sends an initial NAS message or service request to the MMEJJE 101a, which is routed through RN 10 and Donor eNB 30. When a NAS layer in the UE has to send an initial NAS message denoted as 'UE NAS Msg' in fig 3, the UE first initiates the establishment of the Radio Resource Control (RRC) connection over the Uu interface. The RRC procedures are elaborated in 3GPP specification TS 36.331 available at www.3gpp.org. In parallel to the establishment of the RRC connection over the Uu interface, the RN initiates the establishment of the RRC connection over the Un interface. The RRC connection establishment procedure over the Uu and Un interfaces are identical.

The Non-initial NAS message is a ciphered message directed to MME (UE) 101a and the RN 10 is transparent. The MME_UE 101a understands the message and forwards it to the SGW/PGW_UE 102a for checking the UE subscription data (which is to be obtained from HSS 108, fig 1). Then the SGW/PGWJJE 102a authorizes MMEJJE 101a to create a dedicated bearer and sends the message over S11 interface (Interface between S/PGW and MME). On receiving the response, MMEJJE 101a sends bearer setup request to the UE 20 as an S1-AP message routed through RN 10. RN 10 understands this S1-AP message and initiates RRC configuration between UE 20 and RN 10. A bearer setup response is then sent by UE 20 to MMEJJE 101a routed via RN 10 and Donor eNB 30 as an S1-AP message. On receiving the response from UE 20, MMEJJE 101a establishes the bearers and sends the response to SGW/PGWJJE 102a. This process establishes radio bearers to enable data flow from the SGW/PGWJJE 102a to the UE 20. After completion of this procedure, the RN 10 may send a NAS message seeking bearer-resource request to MME_RN 101b through Donor eNB 30. MME_RN 101b understands the message and provisions bearer resource allocation to RN 10. Upon receiving bearer resource allocation, RN 10 bearer establishment is completed. Radio resources for the relay node 10 are allocated so as to serve the already established UE's bearer requirements. The above process of initiating bearer establishment can also be initiated by EPC/Core Network. This happens both when the UE 20 is in the RRCJDLE state and a message/data is to be transported to the UE 20 by the Core Network or when there is a change in existing bearer configuration to the UE 20 in the RRC_CONNECTED state. In this state, MMEJJE 101a initiates bearer-setup or modify procedure for the UE 20 at any point of time based on UE subscription and QoS requirements. Thus in all the above instances of UE NAS Messages, whenever a UE 20 bearer is created or modified, the RN bearer modify or create may be initiated subsequently by the RN 10. Thus additional messages are exchanged separately for the UE 20 and for the RN 10 to modify/create a new bearer. This either wastes or underutilizes the backhaul bandwidth. Further, there is delay in traffic flow.

Figure 4 shows the network nodes conglomeration between two network entities in accordance with the principles of the invention. Network entity 625 is called as Evolved Packet Edge (EPE) comprising of network nodes like UEs, RNs and all other nodes that communicate with Evolved Packet Core Network entity 675 via DeNB. Network nodes in the EPE 625 may establish connectivity external to EPC like Internet 106 or PSTN (Public Switch Telephone Network) 107. EPC entity 675 comprises of network nodes like Mobility Management Entity (MME), Serving gate way/Packet gate way (S/PGW), Policy of Charging Rules Function[PCRF-actually a concatenation of PDF (Policy Decision Function) and CRF (Charging Rules Function) network nodes] etc., These nodes essentially manages the entities in the EPE. For eg., a UE bearer resource request is processed and allowed only by the MME serving the UE. Depending on the complexity of the communication network, it so happens that, MMEs are segregated to perform management of UEs and RNs separately. In such cases, it is appropriate to indicate MMEs serving the UE as MMEJJE and MMEs serving the RNs as MME_RN.
As part of bearer management signalling as envisaged, a communication from EPE 625 comprising of bearer resource request of both the UE and RN is transported via DeNB to EPC as a single signalling message over uplink channel 651 hereinafter referred to as 'Union of Resource Request (UR Request)' message. The response message comprising of bearer resource response from either one of the managing entity or managing entities of EPC 675 are transported as a single signalling message to EPE via DeNB over the downlink channel 652 hereinafter referred to as 'Union of Admission Response (UA Response)'. This manages bearer setup signalling loop, with a single transportation of 'UR Request' signalling message and receiving one 'UA Response' signalling message over uplink and downlink channels respectively.

Figure 5 represents 'UR Request' message signalling in the uplink from EPE 625 to EPC 675 through DeNB 30 in accordance with the embodiments of the invention. When the UE 20 is in the state of RRC_CONNECTED or RRCJDLE; a UE NAS signalling message requesting bearer resource of the form 'Create, Update, Detach, Modify' etc., hereinafter referred to as "CRUD" messages, are generated. It so happens that, depending on the complexity of the EPE communication network, a plurality of RNs may be wirelessly connected in tandem so as to serve a distant UE. In such cases, a bearer request of a UE initiated by sending a UE NAS message to the MME in the EPC 675, has to be routed via all the RNs acting in tandem. Such an arrangement is shown towards the right of EPE 625.

As soon as the UE NAS message generated by UE 20 is received at RN 10a, RN10a adds its identity with the UE NAS message, denoted as 'UE NAS Msg+RNJD 10a' hereinafter referred to as 'tagged message' and routes the tagged message to RN 10b. RN 10b adds its identity with the received tagged message denoted as 'UE NAS Msg+RNJD 10a+RN_ID 10b' and routes the tagged message to RN 10c. RN 10c adds its identity with the received tagged message denoted as 'UE NAS Msg+RNJD 10a+RNJD 10b+RNJD 10c' and routes the tagged message to such 'n' number of RNs, such that it finally ends up with RN 10..n. RN 10..n adds its identity with the received tagged message denoted as 'UE NAS Msg+RNJD 10a+RNJD 10b+RNJD 10c+RNJD 10..n' and forwards to the managing entity of EPC 675 via DeNB 30. The final tagged message is hereinafter referred to as 'RN_TAG'. This RNJTAG message is available at the EPC as 'UR Request' message.
Depending on the complexity of EPE communication network, it so happens that, a single UE may be connected to different RNs. Such circumstances may arise based on the mobility of the UE and/or proximity of the UE with a RN exhibiting excellent signal strength. In such cases, a bearer request of a UE initiated by sending a UE NAS message to the MME in the EPC 675 has to be routed through the respective RN which is coupled to the UE. Such an arrangement is shown towards the left of EPE 625.

As soon as the UE NAS message generated by UE 20 is received at RN 10a, RN10a adds its identity with the UE NAS message, denoted as 'UE NAS Msg+RNJD 10a' which becomes a final tagged message. This final tagged message 'RN_TAG' is forwarded by the RN 10a to the managing entity of EPC 675 through DeNB 30. This RN_TAG message is also available at the EPC as 'UR Request' message.

Figure 6 depicts the 'Union of Admission Response (UA Response)' that are available to RN10. The network nodes MME_UE and MME_RN performing the functions in accordance with the embodiments of the invention are shown in blocks. Block 151 represents the function of granting UE bearer request by the MMEJJE . Block 152 represents the function of MME_RN granting RN bearer request. Block 153 represents the function of MMEJJE not granting UE bearer request. Block 154 represents the function of MME_RN not granting RN bearer request. Block 157 represents the function of DeNB routing the 'Union of Admission response' to RN 10.

If the functions executed in the blocks 151 and 152 are similar (block 155) i.e, if MME_UE and MME_RN both grants the bearer request of UE and RN respectively then the UA Response message that is available to RN 10 is 'UA Response S1-AP Message for UE and S1-AP Message for RN-ACCEPT.

If the functions executed in the blocks 151 and 154 are dissimilar (block 156) i.e., if MME_RN does not grant the RN10 bearer request then the UA Response message that is available to RN 10 is 'UA Response S1-AP Message for UE and S1-AP Message for RN-
REJECT'

It is to be noted that if the MMEJJE does not grant UE bearer request then the UA Response message that is available to RN 10 is 'S1-AP UA REJECT' message. Block 158 is the function of RN 10 receiving one amongst the available union of admission responses.

Figure 7 depicts protocol layers through which insertion of RN_TAG by the RN 10 preferably at any one of the control plane protocol layers of S1-AP, SCTP, NAS or at any one of the other control plane protocol layers is accomplished in accordance with the embodiments of the invention. For the sake of illustration the flow of downlink signalling data in case of two radio bearers is shown with possible RN_TAG insertion points, at any one of the protocol layers. It is to be noted that signalling data flow in case of uplink transmission is similar. For the sake of brevity, the control plane protocol layer 410 above PDCP layer 401 is shown as an integrated layer comprising of NAS, SCTP (Stream Control Transmission Protocol), andS1-AP protocols.

The PDCP layer 401 performs IP-header compression and ciphering. A PDCP header is added, carrying information required for deciphering in the UE. The output from the PDCP is forwarded to the RCL layer 402. The RLC protocol performs concatenation and/or segmentation of the PDCP Service Data Units (SDUs) and adds an RLC header. The RLC Service Data Units (PDUs) are forwarded to the MAC layer 403, which multiplexes a number of RLC SDUs and attaches a MAC header to form a transport block. Finally the Physical layer 404 attaches a CRC (Cyclic Redundancy Check) to the transport block for error-detection purposes and transmits the resulting signal using transmit antennas. In the above protocol structure, possible insertion of RN_TAG 301 (shown by arrow headers) could be at any one of the layers. For eg., RN_TAG 301 can be preferably inserted at header junction of layer 410, or at PDCP header junction of layer 401, or at RLC header junction of layer 402 or at MAC header junction of layer 403 or at any junction of the PHY layer 404. Similarly for each radio bearer signalling flow a possible RN_TAG 301 could be inserted at any one of the protocol layers as explained above.

Figure 8 represents bearer setup signalling loop, with a single transportation of 'UR Request' signalling message and receiving one 'UA Response' signalling message over uplink and downlink channels respectively, in accordance with the embodiments of the present invention. When the UE 20 is in the state of RRC_CONNECTED (1) or RRCJDLE (0), (Step 1) CRUD messages are generated by UE or initiated by EPC. In either case, UE 20 generates either single or multiple bearer within a single NAS message thereby triggering the establishment of RRC connection with the DeNB 30 via RN 10. RN 10 also starts the establishment of the RRC connection with the DeNB 30. Both these RRC procedures over the respective Uu and Un interface are elaborated in 3GPP specification TS 36.331.

When the RN 10 receives the UE NAS Message (Step 2), from UE 20, the RN 10 adds (Step 3) the received'UE NAS Message'with the identity of the said relay node 'RNJD' to be sent to the MME_UE 101a via Donor eNB 30. The denotation " UE NAS Msg+RN_ID"= "RN_TAG" means that it is a final tag message essentially consisting of UE NAS Message and RN 10 Identity. (Step 4). The above denotation is specifically defined for the purpose of this invention as a final tag message denoted as RN_TAG. The RN_TAG is then transmitted from the RN 10 to the MMEJJE 101a via DeNB 30 over Un interface as a control plane signalling message. When this RN_TAG arrives at MMEJJE 101a; the MMEJJE 101a, understands the message (Step 5) and if the 'UE NAS Message' is CRUD message then the MMEJJE 101a processes UE 20's bearer request and grants the request. The granted UE 20 bearer request and the RN 10 identity is then stored in the MMEJJE 101a. Thereafter a 'Relay Node Resource Request (RR REQUEST)' is generated to be sent to MME^RN 101b. (Step 6). If the MMEJJE 101a finds that the UE NAS Message does not pertain to UE 20 bearer request, then the UE NAS Message is handled as any other control plane signalling message. If the MMEJJE 101a does not grant UE 20 bearer request, then MMEJJE 101a generates one 'S1-AP UA REJECT' message for UE 20 and forwards it for UE 20 routed via DeNB 30 andRN 10. (Step 12)
The ' RR REQUEST' message generated by the MMEJJE 101a for MME_RN 101b is a bearer request on behalf of RN 10. The message essentially is an establishment of RN bearer to serve UE's bearer QoS requirements. (For eg., the 'RR REQUEST' message may be that, some bandwidth is guaranteed for the UE 20 which is being served by the RN 10 (RNJD). Hence MME_RN 101b is required to process RN 10 bearer management) (Step 7). The 'RR REQUEST' is then forwarded to MME_RN 101b.

The 'RR REQUEST' is received and understood by the MME_RN 101b. MME_RN 101b has complete knowledge of bandwidth usage at the RN 10. Then, based on the bandwidth requirement, bandwidth usage of the RN 10 and maximum bandwidth limit for the RN 10, MME_RN 101b processes RN 10 bearer request made by MMEJJE 101a. Once RN 10 bearer request is granted, MME_RN 101b generates one 'RR RESPONSE-POSITIVE ACK', and then forwards it to MMEJJE 101a. If the MME_RN 101b does not grant 'RR REQUEST' made by MMEJJE 101a, then MME_RN 101b generates one 'RR RESPONSE-NEGATIVE ACK' , and then forwards it to MMEJJE 101a. (Step 8). MMEJJE 101a receives the 'RR RESPONSE' from the MME_RN 101b (Step 9) and understands it. 'RR RESPONSE' message received from MME_RN 101b is interpreted by MMEJJE 101a and if the message received is 'RR RESPONSE-POSITIVE ACK', from the MME_RN 101b, then MMEJJE generates 'UA RESPONSE ACCEPT message.

The generated UA RESPONSE ACCEPT message is an S1-AP message with an optional element of NAS content inside the said S1-AP message (Step 10). If the message received from MME_RN 101b is an 'RR RESPONSE-NEGATIVE ACK', then MMEJJE generates a 'UA RESPONSE REJECT' message, which is an S1AP message with an optional element of NAS content inside the said S1AP message, and then forwards it to RN 10 (Step 11). Once the above Union of Admission Responses are available at the RN 10, RRC procedures are initiated which is similar to the procedures as elaborated in 3GPP specification TS 36.331 (Step 13). Union of Admission responses forwarded by MMEJJE 101a for UE 20 may be multiplexed, encapsulated or concatenated.

Figures 9 to 12 are flow chart diagrams sequentially arranged (1 to 4) . depicting the functionality of the nodes RN 10, MMEJJE 101a, MME_RN 101b, in accordance with the embodiments of the invention.

Figure 9 represents the functionality 800 of the Relay Node 10 in accordance with the embodiments of the invention. As described above, the embodied functionality of RN 10 begins at 801 wherein it receives UE NAS Message and at 802, irrespective of what UE NAS message contains, RN 10 add its own identity (RNJD) to form a Tagged Message consisting of 'UE NAS Msg + RNJD' and at 803 forwards the tagged message to MMEJJE 101a. RN 10 functionality sequence 1 ends at this stage.

Figure 10 represents the functionality 900 of the MMEJJE 101a as a sequel to RN 10 functionality 800 in accordance with the embodiments of the invention. As explained above, the embodied functionality of MMEJJE 101a begins at 901, wherein it receives the RN_TAG message from RN 10 and at 902 understands the message. At 903, it determines if the received message is a RN_TAG message seeking for bearer establishment of UE 20. If the received message is not a RN_TAG message then it treats it as any other control plane signalling message as shown in 904. If the received message is a RN_TAG message seeking for bearer establishment of UE 20, at 905 it grants the bearer request of UE and at 907, stores the RN 10 Identity and the granted UE resource request. And then it generates a 'RR REQUEST' message as shown in 908. The 'RR REQUEST' message generated for MME_RN 101b is a bearer request on behalf of RN 10. The 'RR REQUEST message is then forwarded to MME_RN 101b as shown in 909. At 905, if the resource request of UE 20 is not granted, then at 906 an 'S1-AP UA REJECT' message is generated and forwarded for UE 20 routed via DeNB 30 and RN 10. MMEJJE 101a functionality sequence 2 ends at this stage.

Figure 11 represents the functionality 1000 of the MME_RN 101b as a sequel to MME_UE 101a functionality 900 in accordance with the embodiments of the invention. As explained above, the embodied functionality of MME_RN 101b begins at 1001, wherein it receives 'RR REQUEST' message and at 1002 understands the message. At 1003, it determines to grant RN 10 bearer request based on the bandwidth requirement, bandwidth usage of the RN 10 and maximum bandwidth limit for the RN 10, as it has complete knowledge of bandwidth usage at the RN 10. Once RN 10 bearer request is granted, an 'RR RESPONSE-POSITIVE ACK' message is generated at 1005 and then it is forwarded to MME_UE 101a at 1006. If RN 10 bearer request made by MMEJJE 101a is not provisioned at 1003, then one 'RR RESPONSE-NEGATIVE ACK' message is generated at 1004 and then forwarded to MMEJJE 101a at 1007. MME_RN 101b functionality sequence 3 ends at this stage.

Figure 12 represents the functionality 1100 of the MMEJJE 101a as a sequel to MME_RN 101b functionality 1000 in accordance with the embodiments of the invention. As explained above, the embodied functionality of MMEJJE 101a in the fourth sequence begins at 1101, wherein it receives 'RR RESPONSE' message from the MME_RN 101b and at 1102 understands it. At 1103, 'RR RESPONSE' message received from MME_RN 101b is interpreted. If the message received is 'RR RESPONSE-POSITIVE ACK' message, then at 1104, MMEJJE 101a generates a 'UA RESPONSE ACCEPT message for UE 20, which is an S1-AP message with an optional element of NAS content inside the said S1-AP message . At 1105, the above message is forwarded for UE via DeNB 30 and RN 10. If the 'RR RESPONSE' message received from MME_RN 101b is a 'RR RESPONSE-NEGATIVE ACK' message, then at 1106 MMEJJE 101a generates a 'UA RESPONSE-REJECT' message for UE 20 which is an S1-AP message with an optional element of NAS content inside the said S1-AP message. At 1107 the above message is forwarded to RN. MME_UE 101a functionality sequence 4 ends at this stage.

Figures 13 to 15 depict systems that can enable the above aspects of the disclosed subject matter. Such systems can include functional blocks, which can be functional blocks that represent functions implemented by a processor or an electronic machine, software or combination thereof.

Figure 13 illustrates a block diagram of an example system 500 that enables the RN 10 functions in accordance with aspects disclosed in the subject specification. System 500 can reside at least partially within a RN. System 500 includes a logical grouping 501 of electronic components that can act in conjunction. In an aspect of the subject innovation, logical grouping includes an electronic component 502 for receiving UE NAS Message and "UA RESPONSE" message; an electronic component 503 for adding the received UE NAS Message with the RN Identity and inserting RN_TAG message at any one of the control plane protocol layers preferably on S1-AP, NAS, SCTP layers; an electronic component 504 for understanding "UA RESPONSE" message ; an electronic component 505 for transmitting RN_TAG message that consists of UE NAS Message and the RN Identity and transmitting radio bearer configuration message for UE. System 500 may also include a memory 506 that retains instructions for executing functions associated with electrical components 502, 503, 504, and 505, as well as measured or computed data that may be generated during executing such functions.

Figure 14 illustrates a block diagram of an example system 600 that enables MMEJJE 101a functions in accordance with aspects disclosed in the subject specification. System 600 can reside at least partially with a MMEJJE. System 600 includes a logical grouping 601 of electronic components that can act in conjunction.

In an aspect of the subject innovation, logical grouping includes an electronic component 602 for receiving RN_TAG message from RN and RR RESPONSE from MME_RN; an electronic component 603 for understanding and ascertaining the RN_TAG message is for bearer request; an electronic component 604 for granting UE resource request if the RN_TAG message is for bearer request; an electronic component 605 for generating a 'RR REQUEST' message seeking bearer establishment for RN if UE resource request is granted; an electronic component 610 for generating a S1-AP UA REJECT message if UE resource request is not granted; an electronic component 609 for treating RN_TAG message as any other control plane signalling message if RN_TAG message is not for bearer request; an electronic component 611 for understanding and ascertaining if the RR RESPONSE message received from MME_RN is RR RESPONSE-POSITIVE ACK; an electronic component 606 for generating UA RESPONSE ACCEPT message if the received message is RR RESPONSE-POSITIVE ACK and generating UA RESPONSE REJECT message if the received message is not RR RESPONSE-POSITIVE ACK; and an electronic component 607 for transmitting RR REQUEST message to MME_RN, transmitting S1-AP REJECT message for UE, transmitting any other control plane signalling message, transmitting UA RESPONSE ACCEPT message for UE and transmitting UA RESPONSE REJECT message for UE. System 600 may also include a memory 608 that retains instructions for executing functions associated with electrical components 602, 603, 604, 605, 606, 607, 609, 610, 611 storing provisioned UE resource request and RN Identity, as well as measured or computed data that may be generated during executing such functions.

Figure 15 illustrates a block diagram of an example system 700 that enables the MME_RN 101b functions in accordance with aspects disclosed in the subject specification. System 700 can reside at least partially within a MME_RN. System 700 includes a logical grouping 701 of electronic components that can act in conjunction. In an aspect of the subject innovation, logical grouping includes an electronic component 702 for receiving RR REQUEST message from MMEJJE; an electronic component 703 for understanding, processing the RR REQUEST message and granting RR REQUEST; an electronic component 704 for provisioning RN resource request made by MME_UE in the New Message on behalf of RN; an electronic component 705 for generating RR RESPONSE-POSITIVE ACK if RN resource request is granted and generating RR RESPONSE-NEGATIVE ACK if RN resource request is not granted; and an electronic component 706 for transmitting either RR RESPONSE-POSITIVE ACK or RR RESPONSE-NEGATIVE ACK to MME_ UE. System 700 may also include a memory 707 that retains instructions for executing functions associated with electrical components 702, 703, , 705 and 706, as well as measured or computed data that may be generated during executing such functions

Memory 506, 608 and 707 described above can be any storage device including any kind of computer readable storage media, for example, RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM, DVD, etc.

Another embodiment of the invention relates to the implementation of the above described various embodiments using hardware and software. It is recognized that the various embodiments of the invention may be implemented or performed using computing devices (processors). A computing device or processor may for eg., be general purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, etc. The various embodiments of the invention may also be performed or embodied by a combination of these devices

Further, the various embodiments of the invention may also be implemented by means of software modules, which are executed by a processor or directly in hardware. Also a combination of software modules and a hardware implementation may be possible. The software modules may be stored on any kind of computer readable storage media, for example RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM, DVD, etc.

It is to be noted that respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method, steps can be realized in individual functional blocks or by individual devices, or one or more of the method, steps can be realized in a single functional block or by a single device.

The present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.

It should be further noted that the individual features of the different embodiments of the invention may individually or in arbitrary combination be subject matter to another invention.

It would be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.

We Claim:

1. A method for bearer management signalling in a communication network, the method comprising of;

Transporting a "Union of Resource Request" (UR Request) message from Evolved Packet Edge (EPE) entities to managing entities of EPE ; and

Receiving "Union of Admission Responses" for the transported UR Request, from one of the said management entity, wherein the said management entity serves/manages all the entities in the EPE.

2. A method for bearer management signalling in a communication network, the method comprising of;

Transporting a "Union of Resource Request" (UR Request) message from Evolved Packet Edge (EPE) entities to managing entities of EPE ; and

Receiving "Union of Admission Responses" for the transported UR Request, from plurality of management entities wherein at least one of the said management entities is not serving/managing the same entities in the EPE.

3. The method of claim 1 and 2 wherein EPE is the conglomeration of nodes those communicate with EPC via DeNB, wherein, the nodes include user equipment (UE) and at least one relay node (RN) and the like.

4. The method of claim 1 and 2 wherein 'managing entities of EPE' are network nodes that manage or administer nodes in the EPE like mobility management entities serving the user equipment (MMEJJE), mobility management entities serving the relay node (MME_RN), serving gate way, packet gate way, PCRF, HSS etc.,

5. The method of claim land 2 wherein "Union of Resource Request" comprises of;

Tagging the UE NAS message received by the relay node in tandem, wherein tagging includes adding relay node identity (RNJD) with the said received UE NAS message and attaching the said tagged message (RN_TAG) at least, in any one of the control plane protocol layers like PDCP, RLC, MAC, PHY and preferably over S1-AP, NAS, SCTP ; and

Forwarding the said tagged message, to the managing entities of EPE.

6. The method of claim 1 and 2 wherein "Union of Resource Request" further comprises of;

Tagging the UE NAS message received by the relay node coupled to a UE, wherein tagging includes adding relay node identity (RNJD) with the said received UE NAS message and attaching the said tag (RN_TAG) at least, in any one of the control plane protocol layers like PDCP, RLC, MAC, PHY and preferably over S1-AP, NAS, SCTP ; and

Forwarding the said tagged message (RN_TAG) to the managing entities of EPE.

7. The method of claim 5 and 6 wherein, RNJD is a relay node identifier comprising MME GROUP ID, MME CODE of MME_RN.

8. The method of claim 1 further comprising of;

Receiving the tagged message by MMEJJE;

Granting "UR Request" by the said MMEJJE, wherein granting includes storing RNJD, understanding,, and creating UA Response message for the said received 'Tagged Message'(RN_TAG); and

Forwarding one among the "Union of Admission Responses" for the said EPE entities, wherein Union of Admission (UA) response includes 'S1-AP UA REJECT' message, 'UA RESPONSE ACCEPT', and 'UA RESPONSE REJECT' messages.

9. The method of Claim 2 further comprising of;

Receiving the tagged message by MMEJJE;

Granting "UR Request" by MMEJJE, wherein granting includes, storing RNJD, understanding, rejecting, accepting, and creating S1-AP UA REJECT, if rejecting, generating relay node resource request ("RR request") message by MMEJJE, if accepting, for the said received 'Tagged Message';

Forwarding the generated RR request message to MME_RN;

Receiving relay node resource response ("RR response") from MME_RN;
Creating UA RESPONSE message; and

Forwarding one among the "Union of Admission Responses" for the said EPE entities by MMEJJE, wherein Union of Admission (UA) response includes 'S1-AP UA REJECT' message, 'UA RESPONSE ACCEPT', and 'UA RESPONSE REJECT messages.

10. The method of claim 9 further comprising of;

Receiving RR request message by MME_RN from MMEJJE;

Granting RR request message by MME_RN, wherein granting includes understanding, rejecting, and generating RR Response message for the said received RR request message; and

Forwarding one among the generated RR response message to MMEJJE, wherein RR response message includes at least one among the 'RR RESPONSE-POSITIVE ACK',
'RR RESPONSE-NEGATIVE ACK'

11. A relay node for bearer management within EPE of a communication network comprising of;

A receiver for receiving at least a UE NAS Message and UA RESPONSE message;

A processor for tagging (RN_TAG), wherein tagging includes adding either the UE NAS message received in tandem by the relay node with the relay node identity(RNJD) or adding the UE NAS message received from the UE coupled to the relay node with the said relay node identity (RNJD);

A processor for attaching the said tag (RN_TAG) at least, in any one of the control plane protocol layers like PDCP, RLC, MAC, PHY, preferably over S1-AP, NAS, SCTP;

A processor for understanding the received union of admission response message from MMEJJE;

A transmitter for transmitting the RN_TAG message to MMEJJE and transmitting the radio bearer configuration message for UE; and

A memory that retains instructions for executing functions associated with the receiver, processor/processors, and transmitter and as well as measured or computed data that may be generated during executing such functions.

12. A system for facilitating bearer management within a communication network comprising:

A receiver that receives at least UE NAS Message comprising information regarding bearer request and receives at least one among the union of admission responses from MMEJJE;

A Processor that adds the received UE NAS Message with the Relay node Identity (RNJD) and tags, wherein the tagged message (RN_TAG) is attached at least in any one of the control plane protocol layers like PDCP, RLC, MAC, PHY, preferably over S1-AP, NAS, SCTP;

A processor for understanding the received union of admission response from MMEJJE;

A transmitter that transmits the tagged (RN_TAG) message to MMEJJE and transmits the radio bearer configuration message for UE; and

A memory that retains instructions for executing functions associated with the receiver, processor/processors, and transmitter and as well as measured or computed data that may be generated during executing such functions.

13. The MME_ UE for bearer management within a communication network
Comprising;

A receiver that receives at least a tagged message (RN_TAG) from relay node comprising UE NAS Message and the relay node identity and for receiving "RR RESPONSE" message from MME_RN;

A processor that understands and ascertains the tagged message (RN_TAG) is UR Request message;

A processor for treating tagged message (RN_TAG) as any other control plane signaling message if the "RN_T AG" is not an UR Request message;

A processor for granting UE resource request;

A processor for generating relay node resource request (RR Request) message, if UE resource request has been granted, and for generating an 'S1-AP UA REJECT' message if the UE resource request has not been granted;

A processor for understanding and ascertaining if the message received from MME_RN is 'RR RESPONSE-POSITIVE ACK';

A processor for generating "UA RESPONSE-ACCEPT" message if 'RR RESPONSE-POSITIVE ACK' is received; and generating "UA RESPONSE-REJECT" message if 'RR RESPONSE-NEGATIVE ACK' is received;

A Transmitter that transmits: "RR REQUEST" message to MME_RN, "S1-AP UA REJECT" message for UE, any other control plane signaling message, "UA RESPONSE ACCEPT" message for UE, and "UA RESPONSE REJECT" message for UE; and

A memory that stores the RNJD from the tagged message and retains instructions for executing functions associated with the receiver, processors, transmitter and as well as measured or computed data that may be generated during executing such functions.

14. A system for facilitating bearer management signaling within a communication network comprising;

A receiver that receives at least a tagged message (RN_TAG) from relay node comprising UE NAS Message and the relay node identity and for receiving "RR RESPONSE" message from MME_RN;

A processor that understands and ascertains the tagged message (RN_TAG) is UR Request message;

A processor for treating tagged message (RN_TAG) as any other control plane signaling message if the "RN_TAG" is not UR Request message;

A processor for granting UE resource request;

A processor for generating relay node resource request (RR Request) message is UE resource request has been granted, and for generating an "S1-AP UA REJECT" message if the UE resource request has not been granted;

A processor for understanding and ascertaining if the message received from MME_RN is 'RR RESPONSE-POSITIVE ACK';

A processor for generating "UA RESPONSE-ACCEPT" message if 'RR RESPONSE-POSITIVE ACK' is received; and generating 'UA RESPONSE-REJECT' message if 'RR
RESPONSE-NEGATIVE ACK' is received;

A Transmitter that transmits: "RR REQUEST" message to MME_RN, "S1-AP UA REJECT" message for UE, any other control plane signaling message, "UA RESPONSE ACCEPT" message for UE, and "UA RESPONSE REJECT" message for UE; and

A memory that stores the RNJD from the tagged message and retains instructions for executing functions associated with the receiver, processors, transmitter and as well as measured or computed data that may be generated during executing such functions.

15. The MME_RN for bearer management within a communication network comprising of;

A receiver that receives at least a "RR REQUEST" message from MMEJJE comprising bearer request for RN;

A processor that understands, processes, and grants the "RR REQUEST" message;

A processor for generating a 'RR RESPONSE-POSITIVE ACK' message if the RR Request has been granted and generating 'RR RESPONSE-NEGATIVE ACK' if the RR Request has not been granted;

A Transmitter that transmits: 'RR RESPONSE-POSITIVE ACK' message to MMEJJE, and 'RR RESPONSE-NEGATIVE ACK' message to MMEJJE; and

A memory that retains instructions for executing functions associated with the receiver, processors, and transmitter and as well as measured or computed data that may be generated during executing such functions.

16. A system for facilitating bearer management within a communication network
Comprising of;

A receiver that receives at least a "RR REQUEST" message from MMEJJE comprising bearer request for RN;

A processor that understands, processes, and grants the "RR REQUEST" message;

A processor for generating a 'RR RESPONSE-POSITIVE ACK' message if the RR Request has been granted and generating 'RR RESPONSE-NEGATIVE ACK' if the RR Request has not been granted;

A Transmitter that transmits: RR RESPONSE-POSITIVE ACK' message to MMEJJE, and 'RR RESPONSE-NEGATIVE ACK' message to MMEJJE; and

A memory that retains instructions for executing functions associated with the receiver, processors, and transmitter and as well as measured or computed data that may be generated during executing such functions.

Documents

Orders

Section Controller Decision Date

Application Documents

# Name Date
1 4459-CHE-2011 FORM-5 20-12-2011.pdf 2011-12-20
1 4459-CHE-2011-Annexure [12-09-2024(online)].pdf 2024-09-12
2 4459-CHE-2011 FORM-3 20-12-2011.pdf 2011-12-20
2 4459-CHE-2011-FORM 13 [12-09-2024(online)].pdf 2024-09-12
3 4459-CHE-2011-FORM-26 [12-09-2024(online)].pdf 2024-09-12
3 4459-CHE-2011 FORM-2 20-12-2011.pdf 2011-12-20
4 4459-CHE-2011-Response to office action [12-09-2024(online)].pdf 2024-09-12
4 4459-CHE-2011 FORM-1 20-12-2011.pdf 2011-12-20
5 4459-CHE-2011-FORM-15 [22-07-2023(online)].pdf 2023-07-22
5 4459-CHE-2011 CORRESPONDENCE OTHERS 20-12-2011.pdf 2011-12-20
6 4459-CHE-2011-POWER OF AUTHORITY [22-07-2023(online)].pdf 2023-07-22
6 4459-CHE-2011 CLAIMS 20-12-2011.pdf 2011-12-20
7 4459-CHE-2011-IntimationOfGrant23-06-2022.pdf 2022-06-23
7 4459-CHE-2011 ABSTRACT 20-12-2011.pdf 2011-12-20
8 4459-CHE-2011-PatentCertificate23-06-2022.pdf 2022-06-23
8 4459-CHE-2011 DRAWINGS 20-12-2011.pdf 2011-12-20
9 4459-CHE-2011 DESCRIPTION (COMPLETE) 20-12-2011.pdf 2011-12-20
9 4459-CHE-2011-PETITION UNDER RULE 137 [23-05-2022(online)].pdf 2022-05-23
10 4459-CHE-2011 OTHER PATENT DOCUMENT 03-02-2012.pdf 2012-02-03
10 4459-CHE-2011-Written submissions and relevant documents [20-05-2022(online)].pdf 2022-05-20
11 4459-CHE-2011 FORM-5 03-02-2012.pdf 2012-02-03
11 4459-CHE-2011-Correspondence to notify the Controller [30-04-2022(online)].pdf 2022-04-30
12 4459-CHE-2011 FORM-3 03-02-2012.pdf 2012-02-03
12 4459-CHE-2011-FORM-26 [30-04-2022(online)].pdf 2022-04-30
13 4459-CHE-2011 FORM-13 03-02-2012.pdf 2012-02-03
13 4459-CHE-2011-US(14)-HearingNotice-(HearingDate-05-05-2022).pdf 2021-12-15
14 4459-CHE-2011 FORM-1 03-02-2012.pdf 2012-02-03
14 4459-CHE-2011-CLAIMS [11-05-2020(online)].pdf 2020-05-11
15 4459-CHE-2011 CORRESPONDENCE OTHERS. 03-02-2012.pdf 2012-02-03
15 4459-CHE-2011-FER_SER_REPLY [11-05-2020(online)].pdf 2020-05-11
16 4459-CHE-2011 AMENDED PAGES OF SPECIFICATION 03-02-2012.pdf 2012-02-03
16 4459-CHE-2011-OTHERS [11-05-2020(online)].pdf 2020-05-11
17 4459-CHE-2011-FER.pdf 2019-11-11
17 4459-CHE-2011 AMENDED CLAIMS 03-02-2012.pdf 2012-02-03
18 4459-CHE-2011 CORRESPONDENCE OTHERS 15-07-2015.pdf 2015-07-15
18 4459-CHE-2011 FORM-9 15-06-2012.pdf 2012-06-15
19 4459-CHE-2011 FORM-3 15-07-2015.pdf 2015-07-15
19 abstract4459-CHE-2011.jpg 2012-06-25
20 4459-CHE-2011 CORRESPONDENCE OTHERS 23-04-2015.pdf 2015-04-23
20 4459-CHE-2011 FORM-13 31-01-2013.pdf 2013-01-31
21 4459-CHE-2011 POWER OF ATTORNEY 31-01-2013.pdf 2013-01-31
21 4459-CHE-2011 FORM-3 23-04-2015.pdf 2015-04-23
22 4459-CHE-2011 CORRESPONDENCE OTHERS 12-02-2013.pdf 2013-02-12
22 4459-CHE-2011 FORM-13 31-01-2013.pdf 2013-01-31
23 4459-CHE-2011 CORRESPONDENCE OTHERS 12-02-2013.pdf 2013-02-12
23 4459-CHE-2011 CORRESPONDENCE OTHERS 31-01-2013.pdf 2013-01-31
24 4459-CHE-2011 FORM-3 12-02-2013.pdf 2013-02-12
25 4459-CHE-2011 CORRESPONDENCE OTHERS 31-01-2013.pdf 2013-01-31
25 4459-CHE-2011 CORRESPONDENCE OTHERS 12-02-2013.pdf 2013-02-12
26 4459-CHE-2011 CORRESPONDENCE OTHERS 12-02-2013.pdf 2013-02-12
26 4459-CHE-2011 FORM-13 31-01-2013.pdf 2013-01-31
27 4459-CHE-2011 POWER OF ATTORNEY 31-01-2013.pdf 2013-01-31
27 4459-CHE-2011 FORM-3 23-04-2015.pdf 2015-04-23
28 4459-CHE-2011 CORRESPONDENCE OTHERS 23-04-2015.pdf 2015-04-23
28 4459-CHE-2011 FORM-13 31-01-2013.pdf 2013-01-31
29 4459-CHE-2011 FORM-3 15-07-2015.pdf 2015-07-15
29 abstract4459-CHE-2011.jpg 2012-06-25
30 4459-CHE-2011 CORRESPONDENCE OTHERS 15-07-2015.pdf 2015-07-15
30 4459-CHE-2011 FORM-9 15-06-2012.pdf 2012-06-15
31 4459-CHE-2011 AMENDED CLAIMS 03-02-2012.pdf 2012-02-03
31 4459-CHE-2011-FER.pdf 2019-11-11
32 4459-CHE-2011 AMENDED PAGES OF SPECIFICATION 03-02-2012.pdf 2012-02-03
32 4459-CHE-2011-OTHERS [11-05-2020(online)].pdf 2020-05-11
33 4459-CHE-2011 CORRESPONDENCE OTHERS. 03-02-2012.pdf 2012-02-03
33 4459-CHE-2011-FER_SER_REPLY [11-05-2020(online)].pdf 2020-05-11
34 4459-CHE-2011 FORM-1 03-02-2012.pdf 2012-02-03
34 4459-CHE-2011-CLAIMS [11-05-2020(online)].pdf 2020-05-11
35 4459-CHE-2011 FORM-13 03-02-2012.pdf 2012-02-03
35 4459-CHE-2011-US(14)-HearingNotice-(HearingDate-05-05-2022).pdf 2021-12-15
36 4459-CHE-2011-FORM-26 [30-04-2022(online)].pdf 2022-04-30
36 4459-CHE-2011 FORM-3 03-02-2012.pdf 2012-02-03
37 4459-CHE-2011 FORM-5 03-02-2012.pdf 2012-02-03
37 4459-CHE-2011-Correspondence to notify the Controller [30-04-2022(online)].pdf 2022-04-30
38 4459-CHE-2011 OTHER PATENT DOCUMENT 03-02-2012.pdf 2012-02-03
38 4459-CHE-2011-Written submissions and relevant documents [20-05-2022(online)].pdf 2022-05-20
39 4459-CHE-2011 DESCRIPTION (COMPLETE) 20-12-2011.pdf 2011-12-20
39 4459-CHE-2011-PETITION UNDER RULE 137 [23-05-2022(online)].pdf 2022-05-23
40 4459-CHE-2011 DRAWINGS 20-12-2011.pdf 2011-12-20
40 4459-CHE-2011-PatentCertificate23-06-2022.pdf 2022-06-23
41 4459-CHE-2011 ABSTRACT 20-12-2011.pdf 2011-12-20
41 4459-CHE-2011-IntimationOfGrant23-06-2022.pdf 2022-06-23
42 4459-CHE-2011-POWER OF AUTHORITY [22-07-2023(online)].pdf 2023-07-22
42 4459-CHE-2011 CLAIMS 20-12-2011.pdf 2011-12-20
43 4459-CHE-2011-FORM-15 [22-07-2023(online)].pdf 2023-07-22
43 4459-CHE-2011 CORRESPONDENCE OTHERS 20-12-2011.pdf 2011-12-20
44 4459-CHE-2011-Response to office action [12-09-2024(online)].pdf 2024-09-12
44 4459-CHE-2011 FORM-1 20-12-2011.pdf 2011-12-20
45 4459-CHE-2011-FORM-26 [12-09-2024(online)].pdf 2024-09-12
45 4459-CHE-2011 FORM-2 20-12-2011.pdf 2011-12-20
46 4459-CHE-2011-FORM 13 [12-09-2024(online)].pdf 2024-09-12
46 4459-CHE-2011 FORM-3 20-12-2011.pdf 2011-12-20
47 4459-CHE-2011 FORM-5 20-12-2011.pdf 2011-12-20
47 4459-CHE-2011-Annexure [12-09-2024(online)].pdf 2024-09-12

Search Strategy

1 2020-09-0114-53-44AE_01-09-2020.pdf
1 searchstrategy_08-11-2019.pdf
2 2020-09-0114-53-44AE_01-09-2020.pdf
2 searchstrategy_08-11-2019.pdf

ERegister / Renewals