Abstract: A network architecture which does not necessitate the presence of routers and Serving Gateways is envisaged. The network architecture includes a modified/specifically configured Mobility Management Entity (MME) termed as Mobility Management Entity – Transport Profile (MME-TP) platform. The MME-TP platform further simplifies the protocol stacks of eNodeB and SGW/PGW, and enables communication between legacy LTE (RAN and EPC) devices and simplified eNodeB and SGW/PGW. By creating tunnels for carrying user plane traffic over a backhaul network, the MME-TP platform obviates the need for Serving Gateways and routers, or at least brings about a reduction in the number of Serving Gateways and router employed across a communication network, thereby reducing at least the costs associated with installing and managing the communication network, and also simplifying the underlying network architecture and imposing a uniformity as far as network configuration is concerned, by obviating the need for managing multiple communication nodes implementing diverse technologies. [FIG.2]
MOBILE MANAGEMENT ENTITY TRANSPORT PROFILE (MME-TP)
PLATFORM
TECHNICAL FIELD
[0001] The present disclosure relates to Mobile Management Systems. Particularly, the present disclosure relates to reconfiguring the communication network architecture to reduce the number of Serving Gateways and routers. More particularly, the present disclosure relates to systems and methods that facilitate replacement of conventional S1 bearers and S5 bearers in an Evolved Packet Core (EPC).
BACKGROUND
[0002] A typical Evolved Packet Core (EPC) framework providing converged voice and data signals on a conventional 4G Long Term Evolution (LTE) network includes a Mobility Management Entity (MME), at least one Serving Gateway (SGW), at least one Packet Data Network Gateway (PGW) amongst other network constituents. Typically, the MME manages session states in addition to tracking and authenticating a user across the 4G network, while the Serving Gateway manages user plane mobility, routes the data packets across the 4G network and also acts as the termination point of the Packet Data Network Interface towards Evolved Universal Mobile Telecommunications System Terrestrial Radio Access (EUTRAN).
[0003] Further, a typical 4G network also includes a Network Management System (NMS) communicating with the backhaul elements constituting a backhaul network that connects the core or backbone network (4G network) with any other smaller sub networks (for example, a base station) and functions as a network intermediary by receiving the data and voice signals from the base station and backhauling them (received data and voice signals) to the 4G network. Further, Serving Gateways (SGW) and Routers typically constituting every 4G network are
expensive and offer a variety of challenges as far as management and maintenance thereof are concerned. Further, the presence of multiple Serving Gateways and Routers also increases the complexity of the underlying network architecture and requires sustained efforts on the part of the network operator as far as network maintenance and trouble shooting is concerned.
[0004] In a typical scenario involving the implementation of a 4G network, a network connection for a Mobile Station (MS) or a User Equipment (UE) is established when the MME sets up the following network connections: a Radio Access Bearer (RAB) connection between the MS/UE and the corresponding eNodeB; an S1-UP tunnel or an S1 bearer connection between the eNodeB and the Serving Gateway (SGW); and an S5 bearer connection the Serving Gateway (SGW) and the Packet Data Network Gateway (PGW). During connection setup phase, the network elements and the eNodeB and EPC elements such as the MME, SGW, PGW exchange user plane traffic and control plane traffic via the underlying backhaul network. Typically, the connection between the network elements and the EPC elements is overlaid on the backhaul network as shown in FIG.1A and therefore the S1 bearer and S5 bearer are consequently backhauled over the backhaul network.
[0005] However, as described above, since the bearers and Serving Gateways are expensive and since their presence increases the complexity of the underlying network architecture and necessitates sustained efforts on the part of the network operator as far as network maintenance and trouble shooting is concerned, there has been felt a need to eliminate the use of S1 bearers, S5 bearers and Serving Gateways in the 4G (LTE) network or at least substantially reduce the number of S1 bearers, S5 bearers and Serving Gateways used in the 4G (LTE) network.
[0006] One of the approaches to address the aforementioned need was to configure the MME to setup communication tunnels for transmitting user plane traffic over the backhaul network and between the backhaul network elements,
instead of carrying the user plane traffic between the EPC elements, thereby either eliminating the use of S1 bearers, S5 bearers and Serving Gateways, or at least substantially reducing the number of S1 bearers, S5 bearers and Serving Gateways used in the 4G (LTE) network. However, the aforementioned approach was required to be implemented taking into consideration the phenomenon of the MME not being designed/configured to communicate with backhaul network elements, and therefore mandating the presence of the NMS for establishing a communication link with the backhaul network elements despite the NMS not being designed/configured to communicate with the EPC elements forming a central part of the 4G network.
OBJECTS
[0007] An object of the present disclosure is to redesign the Evolved Packet Core (EPC) network by reducing the number of S1/S5 and S8 bearers incorporated therein.
[0008] Yet another object of the present disclosure is to simplify the Evolved Packet Core (EPC) network architecture by eliminating the use of S1/S5 and S8 bearers.
[0009] One more object of the present disclosure is to envisage an MME-TP platform agnostic to the absence of Serving Gateways. Still a further object of the present disclosure is to envisage improved and enhanced utilization of backhaul network elements in an LTE communication network.
[0010] Yet another object of the present disclosure is to envisage a cost effective network topology.
[0011] One more object of the present disclosure is to promote reuse of existing backhaul network infrastructure.
SUMMARY
[0012] The present disclosure envisages a network architecture which does not necessitate the presence of routers and Serving Gateways (SGW). The network architecture envisaged by the present disclosure includes a modified/specifically configured Mobility Management Entity (MME) termed as Mobility Management Entity – Transport Profile (MME-TP) platform. The MME-TP platform further simplifies the protocol stacks of eNodeB and SGW/PGW, and enables communication between legacy LTE (RAN and EPC) devices and (the) simplified eNodeB and SGW/PGW.
[0013] In accordance with the present disclosure, by creating tunnels for carrying user plane traffic over a backhaul network, the MME-TP platform obviates the need for Serving Gateways (SGW) and routers, or at least brings about a reduction in the number of Serving Gateways and router employed across a communication network (for example, a 4G communication network), thereby reducing at least the costs associated with installing and managing the communication network, and also simplifying the underlying network architecture and imposing a uniformity (across the communication network) as far as network configuration is concerned, by obviating the need for managing multiple communication nodes implementing diverse technologies.
[0014] Prior art Mobility Management Entities (MMEs) typically interact with Serving Gateways (SGW) over an S11 interface and exchange S11 control packets. Typically, the S11 control packets contain information (including the IP address) identifying the tunnel end-points between which the tunnels are to be created. Subsequently, the Serving Gateways signal the identified tunnel end-points and create tunnel(s) between the respective end-points. Typically, the Serving Gateways are IP/Layer 3 routers configured to receive and interpret S11 control packets, and subsequently create S1/S5/S8 tunnels (as defined in 3GPP TS 29.060, 3GPP TS 29.274, and 3GPP TS 29.281).
[0015] In contrast, the MME-TP platform envisaged by the present disclosure interacts with the backhaul network elements to create the access tunnel in the access network and the metro tunnel in the metro network. The access tunnel communicably couples the eNodeB with a metro switch, and the metro tunnel communicably couples the metro switch with the Packet Data Network Gateway. Alternatively, the Packet Data Network Gateway could be communicably coupled to a second eNodeB via at least a second access tunnel.
[0016] The communication network necessitates the tunnels (metro tunnel and access tunnel) to transmit data between a Radio Access Network (that typically connects a User Equipment to a corresponding eNodeB) and the Packet Data Network Gateway. Since the metro tunnel and access tunnel in combination communicably couple the eNodeB with the Packet Data Network Gateway, the communication network is rendered capable of functioning without the S1/S5/S8 tunnels (router interfaces) which typically transmit user plane data and control plane data between the eNodeB, the Serving Gateways and the Packet Data Network Gateway.
[0017] The communication network as envisaged by the present disclosure is configured to incorporate the metro tunnel and the access tunnel as replacements for (expensive) S1/S5/S8 interfaces, since the Radio Access Network and the Packet Data Network Gateway are communicably coupled by the metro tunnel and the access tunnel, and since no routing protocols and router interfaces (S1/S5/S8) are required to transmit data (user plane data and control plane data) between two communicably coupled locations of the communication network, i.e., the Radio Access Network and the Packet Data Network Gateway.
[0018] Further, in accordance with the present disclosure, the user plane data and the control plane data are transmitted from the access tunnel (formed over an access network) to the Packet Data Network Gateway via pre-existing backhaul elements constituting a backhaul network, thereby enabling the communication network to be implemented without S1, S5 and S8 router interfaces.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
[0019] FIG.1A is block diagram illustrating a prior-art communication network incorporating legacy eNodeBs and Serving Gateways (SGWs);
[0020] FIG.1B is a block diagram illustrating the architecture of a communication network incorporating an MME-TP platform in accordance with the present disclosure;
[0021] FIG.2A represents user plane protocol stack and FIG.2B represents control plane protocol stack, subsequent to replacing the S1/S5/S8 bearers with the metro tunnel and access tunnel; and
[0022] FIG.3 is a flowchart illustrating the steps involved in the method for creating at least two Multiprotocol Label Switching-Transport Profile (MPLS-TP) tunnels using a mobile management entity transport profile (MME-TP) platform.
DETAILED DESCRIPTION
[0023] In order to obviate the drawbacks discussed hitherto, the present disclosure envisages a network architecture which does not necessitate the presence of routers and Serving Gateways (SGW). The network architecture envisaged by the present disclosure includes a modified/specifically configured Mobility Management Entity (MME) termed as Mobility Management Entity – Transport Profile (MME-TP) platform.
[0024] In accordance with the present disclosure, by creating tunnels for carrying user plane traffic over a backhaul network, the MME-TP platform obviates the need for Serving Gateways (SGW) and routers, or at least brings about a reduction in the number of Serving Gateways and router employed across a communication network (for example, a 4G communication network), thereby reducing at least the costs associated with installing and managing the communication network, and also simplifying the underlying network architecture and imposing a uniformity (across the communication network) as far as network configuration is concerned, by obviating the need for managing multiple communication nodes implementing diverse technologies.
[0025] Referring to FIG.1B, there is shown a block diagram illustrating the architecture of an exemplary communication network 100, in accordance with the present disclosure. As shown in FIG.1B, the communication network 100 includes a Mobility Management Entity – Transport Profile (MME-TP) platform denoted by reference numeral 10. While the MME-TP platform 10 communicates with an eNodeB 14 via an S1-Control Plane (S1-CP) or S1-MME interface, and receives (any) S1- CP messages from the eNodeB 14.
[0026] In accordance with the present disclosure, the MME-TP platform 10 is configured to create at least two Multiprotocol Label Switching-Transport Profile (MPLS-TP) tunnels. The two MPLS-TP tunnels created by the MME-TP platform 10 include a metro tunnel 10A over a metro network and an access tunnel 10B over an access network. Any of the well known technologies and standards including Institute of Electrical and Electronics Engineers’ (IEEE) Provider Backbone Bridging Network (PBBN), Internet Engineering Task Force’s (IETF) Multi Protocol Label Switching (MPLS) and Multi Protocol Label Switching – Transport Profile (MPLS-TP), Telecommunication Standardization Sector of the International Telecommunications Union (ITU-T) Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), are utilized by the MME-TP platform 10 to
create the metro tunnel 10A and the access tunnel 10B. In accordance with the present disclosure, the access tunnel 10B communicably couples the eNodeB 14 with a metro switch, and the metro tunnel 10A communicably couples the metro switch to a Packet Data Network Gateway 16 (PGW).
[0027] In accordance with the present disclosure, the MME-TP platform 10 includes an Evolved Packet System Mobility Management (EMM) module configured to determine and maintain a log of EMM states corresponding to at least one User Equipment (not shown in figures) communicably coupled to the eNodeB 14. Typically, the communicable coupling of the User Equipment and the eNodeB forms a Radio Access Network (RAN). The EMM states maintained by the EMM module indicate whether the User Equipment (communicably coupled to the eNodeB 14) is accessible at any particular point of time via the RAN, thereby further indicating the signal connectivity between the User Equipment and the eNodeB 14. The two EMM states maintained by the EMM module include EMM_REGISTERED state and EMM_DEREGISTERED state.
[0028] Typically, in the EMM_DEREGISTERED state, the EMM context in the MME-TP 10 holds no location information and valid routing information corresponding to the User Equipment, thereby signifying that the User Equipment is not reachable by the MME-TP 10. Typically, the User Equipment enters the EMM_REGISTERED by a successful registration with an attach procedure to the RAN (for E-UTRAN in case of an LTE network). In the EMM_REGISTERED state the User Equipment is rendered capable of receiving services that mandate the User Equipment to be registered with Evolved Packet System (EPS). Further, in the EMM_REGISTERED state, the location of the User Equipment is known to the MME-TP 10.
[0029] In accordance with the present disclosure, the MME-TP platform 10 further includes an Evolved Packet System Connection Management (ECM) module configured to determine and maintain a log of ECM states corresponding to the User Equipment communicably coupled to the eNodeB 14. The two ECM states maintained by the ECM module include ECM_IDLE state and ECM_CONNECTED state. In the ECM_IDLE state, there is no S1_MME connection for the User Equipment, and there exists no Non-Access Stratum (NAS) signaling between the User Equipment and the RAN. Further, in the ECM_CONNECTED state, there exists a signaling connection between the User Equipment and the MME-TP 10, and the location of the User Equipment is known in the MME-TP 10. Further, in the ECM_CONNECTED state the MME-TP 10 is informed of the eNodeB (eNodeB ID) serving the User Equipment.
[0030] In accordance with the present disclosure, the User Equipment communicates with the eNodeB 14 and the MME-TP platform 10 via RAN. The eNodeB 14 communicates with the MME-TP platform 10 using an S1-MME interface, and the MME-TP platform 10 is configured to create the access tunnel 10B and metro tunnel 10A subsequent to receiving an S1-MME message from the eNodeB 14, and subsequently identifies the end-points of the access tunnel 10B and metro tunnel 10A.
[0031] In accordance with the present disclosure, the MME-TP configures the devices or equipments or switches (respective access switches and metro switches) that enable establishment of the metro tunnel 10A and the access tunnel 10B respectively.
[0032] Prior art Mobility Management Entities typically interact with Serving Gateways (SGW) over an S11 interface and exchange S11 control packets. Typically, the S11 control packets contain information (including the IP address) identifying the tunnel end-points between which the tunnels are to be created. Subsequently, the Serving Gateways signal the identified tunnel end-points and
create tunnel(s) between the respective end-points. Typically, the Serving Gateways are IP/Layer 3 routers configured to receive and interpret S11 control packets, and subsequently create S1/S5/S8 tunnels.
[0033] In contrast, the MME-TP platform 10 envisaged by the present disclosure creates the access tunnel 10B in the access network and the metro tunnel 10A in the metro network. The access tunnel 10B communicably couples the eNodeB 14 with a metro switch, and the metro tunnel 10A communicably couples the metro switch with the Packet Data Network Gateway.
[0034] The communication network 100 necessitates the tunnels (metro tunnel 10A and access tunnel 10B) to transmit data between a Radio Access Network (that typically connects a User Equipment to a corresponding eNodeB) and the Packet Data Network Gateway. Since the metro tunnel 10A and access tunnel 10B in combination communicably couple the eNodeB 14 with the Packet Data Network Gateway, the communication network 100 is rendered capable of functioning without the S1/S5/S8 tunnels (router interfaces) which typically transmit user plane data and control plane data between the eNodeB 14, the Serving Gateways and the Packet Data Network Gateway.
[0035] The communication network 100 as envisaged by the present disclosure is configured to incorporate the metro tunnel 10A and the access tunnel 10B as replacements for (expensive) S1/S5/S8 interfaces, since the Radio Access Network and the Packet Data Network Gateway are communicably coupled by the metro tunnel 10A and the access tunnel 10B, and since no routing protocols and router interfaces (S1/S5/S8) are required to transmit data (user plane data and control plane data) between two communicably coupled locations of the communication network, i.e., the Radio Access Network and the Packet Data Network Gateway.
[0036] Further, in accordance with the present disclosure, the user plane data and the control plane data are transmitted from the access tunnel 10B (formed over an access network) to the Packet Data Network Gateway via pre-existing backhaul elements constituting a backhaul network, thereby enabling the communication network 100 to be implemented without S1, S5 and S8 router interfaces. The backhaul network is selected from the group of backhaul networks consisting of Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), Plesiochronous Digital Hierarchy (PDH), Optical Transport Network (OTN), Gigabit Passive Optical Network (GPON), Dense Wavelength Division Multiplexing (DWDM), Ethernet, and Asynchronous Transfer Mode (ATM).
[0037] In accordance with the present disclosure, the metro tunnel 10A and the access tunnel 10B replace the conventional S1, S5 and S8 tunnels (interfaces) previously used for carrying user plane traffic and control plane traffic. In the event that the eNodeB 14 does not support MPLS-TP header, then a tunnel (access tunnel 10B) is established between an access switch connecting the eNodeB 14 with the User Equipment. Subsequently, the Access switch maps all the (data) traffic received from the eNodeB 14 over the access tunnel 10B. The mapping used for transmitting the UE traffic via the access tunnel 10B is termed Traffic Flow Template (TFT). In accordance with the present disclosure, the access switch performs Deep packet inspection (DPI) and subsequently maps the UE packets to MPLS-TP tunnel. Deep packet inspection (DPI) is performed by the access switch to perform mapping function equivalent to that of the mapping of the UE packet into GTP-U tunnel at the legacy eNodeB. In this manner the UE packets received via eNodeB over the client port are mapped or tunneled through appropriate access and metro tunnel. Typically, this mapping also satisfies the TFT. When DPI is performed, legacy eNodeB and PGW may be provisioned without GTP-u layer or with default/fixed GTP-u headers because TFT, Quality of Service (QoS) and tunneling is taken care of by backhaul tunnels.
[0038] When the User Equipment undergoes a handover, at least three bi-directional access tunnels are established, including a first access tunnel from a source eNodeB to a metro switch, a second access tunnel from a target eNodeB to the metro switch and thirdly between the source eNodeB and the target eNodeB. In accordance with the present disclosure, the tunnels could be established over multiple backhaul ring networks, but for the sake of brevity, only two rings, i.e. the access ring and metro ring are shown in FIG.1B.
[0039] Referring to FIG.2A and FIG.2B in combination, there are shown the EPC elements, the corresponding protocol stack and the modifications inflicted onto the protocol stack of the EPC elements subsequent to replacing the S1/S5/S8 bearers with the metro tunnel 10A and access tunnel 10B. FIG.2A describes the data plane protocol stack for each of the EPC elements and FIG.2B describes the control plane stack for each of the EPC elements. As shown in FIG.2A, the data plane protocol stack is simplified by elimination of GTP tunnel over UDP over IP (as denoted by crossed out nomenclature). Further, as shown in FIG.2A, L2 is MPLS-TP stack (along with appropriate L2 headers such as Ethernet or ATM, and the like (not shown in figures)) that enables establishment of Layer 2 tunnels as a replacement for S1 and S5 interfaces. Further, as illustrated in FIG.2A, the eNodeB stack and the PGW are also simplified. Referring to FIG.2B, the SCTP stack and IP stack of the control plane could be selectively removed, and the S1-AP could be piggybacked over L2 in a manner similar to that of carrying data-link control packets over Ethernet. In this manner, as described in FIG.2A and FIG.2B, new (and simplified) versions of eNodeB and PGW are created.
[0040] Referring to FIG.3, there is shown a flowchart illustrating the steps involved in the method for creating at least two Multiprotocol Label Switching-Transport Profile (MPLS-TP) tunnels using a mobile management entity transport profile (MME-TP) platform. As illustrated in FIG.3, at step 300 the MME-TP platform creates at least two MPLS-TP tunnels, with a first tunnel being an access
tunnel and a second tunnel being a metro tunnel. The metro tunnel and access tunnel in combination communicably couple an eNodeB - which is in turn communicating with at least one User Equipment (UE) – with at least one Packet Data Network Gateway (PGW). Further, at step 302, the conventional S1 bearers and S5 bearers of a typical communication network are replaced by the combination of access tunnel and metro tunnel. Typically the communication network necessitates the metro tunnel and access tunnel to transmit data between a Radio Access Network (that typically connects a User Equipment to a corresponding eNodeB) and the Packet Data Network Gateway. Since the metro tunnel and access tunnel in combination communicably couple the eNodeB with the Packet Data Network Gateway, the communication network is rendered capable of functioning without the conventional S1/S5/S8 tunnels (router interfaces) which typically transmit user plane data and control plane data between the eNodeB 14, the Serving Gateways and the Packet Data Network Gateway.
[0041] In accordance with the present disclosure, the MME-TP platform communicates with the eNodeB via an S1-MME interface. The MME-TP notifies the eNodeB about the establishment of the metro tunnel and the access tunnel, via the S1-MME interface. Further, the eNodeB is communicably coupled with a metro switch via said access tunnel, and wherein said metro switch is selectively coupled to a second eNodeB via a second access tunnel, said metro switch selectively coupled to a Packet Data Network Gateway (PGW) via said metro tunnel.
TECHNICAL ADVANTAGES
[0042] The technical advantages envisaged by the present disclosure include the realization of a communication network configured to incorporate a metro tunnel and an access tunnel as replacements for (expensive) S1/S5/S8 interfaces, and provide for a seamless between a Radio Access Network and a Packet Data Network Gateway without necessitating any routing protocols and corresponding router
interfaces. Further, the present disclosure envisages redesigning the Evolved Packet Core (EPC) network by reducing the number of S1/S5 and S8 bearers incorporated therein, in addition to simplifying the EPC network architecture by eliminating the use of S1/S5 and S8 bearers. The present disclosure proposes improved and enhanced utilization of backhaul network elements in an LTE communication network, and also renders the LTE communication network cost effective, by promoting reuse of existing backhaul network elements within the LTE communication network.
We Claim:
1. A mobile management entity transport profile (MME-TP) platform, said MME-TP platform configured to create at least two communication tunnels using at least one backhaul network, said two communication tunnels being Multiprotocol Label Switching-Transport Profile tunnels (MPLS-TP), said MPLS-TP tunnels including an access tunnel and a metro tunnel, said MPLS-TP tunnels replacing S1-UP bearers and S5/S8 bearers of Evolved Packet Core (EPC).
2. The MME-TP platform as claimed in claim 1, wherein the said backhaul network is selected from a group of backhaul networks consisting of Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), Plesiochronous Digital Hierarchy (PDH), Optical Transport Network (OTN), Gigabit Passive Optical Network (GPON), Dense Wavelength Division Multiplexing (DWDM), Ethernet, and Asynchronous Transfer Mode (ATM).
3. The MME-TP platform as claimed in claim 1, wherein the MME-TP platform further comprises an Evolved Packet System Mobility Management (EMM) module, said EMM module configured to determine and maintain a log of EMM states corresponding to at least one User Equipment communicably coupled to an eNodeB thereby forming a Radio Access Network (RAN), said EMM states indicative of accessibility of said User Equipment.
4. The MME-TP platform as claimed in claim 1, wherein the MME-TP platform further comprises an Evolved Packet System Connection Management (ECM) module, said ECM module configured to determine and maintain a log of ECM states corresponding to at least the User Equipment communicably coupled to said eNodeB, said ECM states indicative of a signal connectivity between said User Equipment and a peer equipment of said User Equipment, said peer equipment selected from a group consisting of a voice gateway, a packet gateway and a second User Equipment.
5. The MME-TP platform as claimed in claim 1 or 2, wherein said MME-TP platform is further configured to interpret S1-MME messages received from the Radio Access Network (RAN), said MME-TP platform further configured to identify end points of the MPLS-TP tunnels subsequent to receiving an S1-MME message from said RAN.
6. The MME-TP platform as claimed in claim 1, wherein the MME-TP platform communicates with said eNodeB over an S1-MME interface, said MME-TP platform further configured to notify said eNodeB about establishment of a communication link, subsequent to creating said at least two tunnels.
7. The MME-TP platform as claimed in claim 1, wherein said eNodeB is communicably coupled with a metro switch via said access tunnel, and wherein said metro switch is selectively coupled to a second eNodeB via a second access tunnel, said metro switch selectively coupled to a Packet Data Network Gateway (PGW) via said metro tunnel.
8. A method for creating at least two Multiprotocol Label Switching-Transport Profile (MPLS-TP) tunnels using a mobile management entity transport profile (MME-TP) platform, said method comprising the following steps:
configuring said MME-TP platform to create said at least two MPLS-TP tunnels using a backhaul network for communicably coupling at least one eNodeB with at least one Packet Data Network Gateway (PGW), said at least two MPLS-TP tunnels including a metro tunnel and an access tunnel; and
replacing S1-UP bearers, S5 and S8 bearers with said at least two MPLS-TP tunnels.
9. The method as claimed in claim 8, wherein the method further includes the step of
communicably coupling said MME-TP platform with said eNodeB using an S1-
MME interface, and further configuring said MME-TP platform to notify said
eNodeB about a connection establishment via said S1-MME interface,
subsequent to creating said at least two MPLS-TP tunnels.
10. The method as claimed in claim 8 or 9, wherein the method further includes the
step of communicably coupling said eNodeB with a metro switch using said
access tunnel, and communicably coupling said metro switch with a Packet Data
Network Gateway (PGW)or at least one another eNodeB via at least one another
access tunnel using said metro tunnel.
| # | Name | Date |
|---|---|---|
| 1 | Power of Attorney [22-06-2017(online)].pdf | 2017-06-22 |
| 2 | Form 5 [22-06-2017(online)].pdf | 2017-06-22 |
| 3 | Form 3 [22-06-2017(online)].pdf | 2017-06-22 |
| 4 | Form 18 [22-06-2017(online)].pdf_221.pdf | 2017-06-22 |
| 5 | Form 18 [22-06-2017(online)].pdf | 2017-06-22 |
| 6 | Form 1 [22-06-2017(online)].pdf | 2017-06-22 |
| 7 | Drawing [22-06-2017(online)].pdf | 2017-06-22 |
| 8 | Description(Complete) [22-06-2017(online)].pdf_220.pdf | 2017-06-22 |
| 9 | Description(Complete) [22-06-2017(online)].pdf | 2017-06-22 |
| 10 | abstract 201741021987 .jpg | 2017-06-29 |
| 11 | PROOF OF RIGHT [06-07-2017(online)].pdf | 2017-07-06 |
| 12 | 201741021987-REQUEST FOR CERTIFIED COPY [22-09-2018(online)].pdf | 2018-09-22 |
| 13 | 201741021987-REQUEST FOR CERTIFIED COPY [22-09-2018(online)]-1.pdf | 2018-09-22 |
| 14 | 201741021987-OTHERS [22-09-2018(online)].pdf | 2018-09-22 |
| 15 | 201741021987-OTHERS [22-09-2018(online)]-1.pdf | 2018-09-22 |
| 16 | 201741021987-FORM28 [22-09-2018(online)].pdf | 2018-09-22 |
| 17 | 201741021987-FORM28 [22-09-2018(online)]-1.pdf | 2018-09-22 |
| 18 | 201741021987-FORM FOR SMALL ENTITY [22-09-2018(online)].pdf | 2018-09-22 |
| 19 | 201741021987-FORM FOR SMALL ENTITY [22-09-2018(online)]-1.pdf | 2018-09-22 |
| 20 | 201741021987-EVIDENCE FOR REGISTRATION UNDER SSI [22-09-2018(online)].pdf | 2018-09-22 |
| 21 | 201741021987-EVIDENCE FOR REGISTRATION UNDER SSI [22-09-2018(online)]-1.pdf | 2018-09-22 |
| 22 | 201741021987-RELEVANT DOCUMENTS [31-07-2019(online)].pdf | 2019-07-31 |
| 23 | 201741021987-FORM 13 [31-07-2019(online)].pdf | 2019-07-31 |
| 24 | 201741021987-FORM 3 [03-08-2019(online)].pdf | 2019-08-03 |
| 25 | 201741021987-FER.pdf | 2020-05-01 |
| 26 | 201741021987-FORM 4(ii) [30-10-2020(online)].pdf | 2020-10-30 |
| 27 | 201741021987-FORM 3 [27-11-2020(online)].pdf | 2020-11-27 |
| 28 | 201741021987-RELEVANT DOCUMENTS [01-12-2020(online)].pdf | 2020-12-01 |
| 29 | 201741021987-PETITION UNDER RULE 137 [01-12-2020(online)].pdf | 2020-12-01 |
| 30 | 201741021987-OTHERS [01-12-2020(online)].pdf | 2020-12-01 |
| 31 | 201741021987-MARKED COPIES OF AMENDEMENTS [01-12-2020(online)].pdf | 2020-12-01 |
| 32 | 201741021987-FORM 13 [01-12-2020(online)].pdf | 2020-12-01 |
| 33 | 201741021987-FER_SER_REPLY [01-12-2020(online)].pdf | 2020-12-01 |
| 34 | 201741021987-DRAWING [01-12-2020(online)].pdf | 2020-12-01 |
| 35 | 201741021987-CORRESPONDENCE [01-12-2020(online)].pdf | 2020-12-01 |
| 36 | 201741021987-COMPLETE SPECIFICATION [01-12-2020(online)].pdf | 2020-12-01 |
| 37 | 201741021987-CLAIMS [01-12-2020(online)].pdf | 2020-12-01 |
| 38 | 201741021987-AMMENDED DOCUMENTS [01-12-2020(online)].pdf | 2020-12-01 |
| 39 | 201741021987-ABSTRACT [01-12-2020(online)].pdf | 2020-12-01 |
| 40 | 201741021987-PatentCertificate11-04-2023.pdf | 2023-04-11 |
| 41 | 201741021987-IntimationOfGrant11-04-2023.pdf | 2023-04-11 |
| 42 | 201741021987-OTHERS [05-07-2023(online)].pdf | 2023-07-05 |
| 43 | 201741021987-FORM FOR SMALL ENTITY [05-07-2023(online)].pdf | 2023-07-05 |
| 44 | 201741021987-EVIDENCE FOR REGISTRATION UNDER SSI [05-07-2023(online)].pdf | 2023-07-05 |
| 45 | 201741021987-PROOF OF ALTERATION [11-04-2024(online)].pdf | 2024-04-11 |
| 1 | 2019-12-1912-28-30_19-12-2019.pdf |