EP4211987A1 - Architecture de système de passerelle hetnet 2g - Google Patents

Architecture de système de passerelle hetnet 2g

Info

Publication number
EP4211987A1
EP4211987A1 EP21867541.1A EP21867541A EP4211987A1 EP 4211987 A1 EP4211987 A1 EP 4211987A1 EP 21867541 A EP21867541 A EP 21867541A EP 4211987 A1 EP4211987 A1 EP 4211987A1
Authority
EP
European Patent Office
Prior art keywords
cws
hng
bts
bsc
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21867541.1A
Other languages
German (de)
English (en)
Inventor
Rajesh Kumar Mishra
Yang Cao
Kartik Shashikant Raval
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Parallel Wireless Inc
Original Assignee
Parallel Wireless Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/014,346 external-priority patent/US20210227405A1/en
Application filed by Parallel Wireless Inc filed Critical Parallel Wireless Inc
Publication of EP4211987A1 publication Critical patent/EP4211987A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16—Gateway arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels

Definitions

  • GSM/2G is a mature telecom technology primarily used for Voice Service.
  • GSM/2G has widespread use throughout the world and extensive coverage.
  • GSM service is in more than 200 different countries, which makes it easy to use a GSM phone in those countries.
  • Many operators use GSM/2G to deliver voice services; for example, operators in developing countries.
  • a GSM cell phone will work with any other GSM service anywhere in the world if it has the same frequency.
  • GPRS technology brings many benefits for users and network operators alike over the basic GSM system.
  • Parallel Wireless’s all-G software platform empowers MNOs to cost-effectively connect everyone everywhere. In 2020 it is estimated that there will be nearly 39% more 2G connections worldwide than there are 4G. With so many people still using 2G, you would think operators would be eager to capture this market share, yet few are.
  • the wireless network system includes a 2G Base Station Subsystem (BSS) managing a circuit switched (CS) path wherein a remote gateway (RGW) runs inside a converged wireless system (CWS) and handles radio resource management functions, the RGW including a standardized interface towards the BTS software within the CWS, and wherein communication between the BTS layers and RGW layers uses Abis over IP interface.
  • BSS Base Station Subsystem
  • RGW remote gateway
  • the 2G BSS manages a packet switched path, wherein the CWS hosts a Packet Control Unit (PCU) function.
  • PCU Packet Control Unit
  • a virtualized Hetnet Gateway (HNG) for a 2G network comprises a processor; and a memory coupled to the processor, the memory containing instructions which, when executed by the processor, cause the base station to provide a virtual machine for 2G networks; wherein the virtual machine provide a plurality of virtualized network functions (VNFs).
  • VNFs virtualized network functions
  • a method comprises causing a processor to provide a virtual machine for 2G networks; wherein the virtual machine provide a plurality of virtualized network functions (VNFs).
  • VNFs virtualized network functions
  • a non-transitory computer-readable medium containing instructions which, when executed at a processor, causes the processor to perform steps comprising: providing a virtual machine for 2G networks; wherein the virtual machine provide a plurality of virtualized network functions (VNFs).
  • VNFs virtualized network functions
  • FIG. l is a diagram of a modernized legacy 2G network, in accordance with some embodiments.
  • FIG. 2 is a diagram showing satellite and microwave backhaul, in accordance with some embodiments.
  • FIG. 3 is a diagram showing 2G architecture simplification, in accordance with some embodiments.
  • FIG. 4 is a diagram showing All G software platform, in accordance with some embodiments.
  • FIG. 5 is a diagram of a 2G BSS, in accordance with some embodiments.
  • FIG. 6 is another diagram of a 2G BSS, in accordance with some embodiments.
  • FIG. 7 is a diagram showing steps connecting the HNG and the MSC, in accordance with some embodiments.
  • FIG. 8 is a call flow diagram showing a location update, in accordance with some embodiments.
  • FIG. 9 is a call flow diagram showing a mobile originating mobile terminating call, in accordance with some embodiments.
  • FIG. 10 is a call flow diagram showing PS initialization, in accordance with some embodiments.
  • FIG. 11 is a call flow diagram showing GPRS attach and PDP context activation, in accordance with some embodiments.
  • FIG. 12 is a call flow diagram showing SMS mobile originating mobile terminating, in accordance with some embodiments.
  • FIG. 13 is a block diagram showing a BTS ingress demux, in accordance with some embodiments.
  • FIG. 14 is a block diagram showing a BTS egress demux, in accordance with some embodiments.
  • FIG. 15 is a call flow diagram showing a location update call flow, in accordance with some embodiments.
  • FIG. 16 is a call flow diagram showing mobile originating call flow, in accordance with some embodiments.
  • FIG. 17 is a call flow diagram showing an SMS mobile originating call flow, in accordance with some embodiments.
  • FIG. 18 is a block diagram showing an ingress demux, in accordance with some embodiments.
  • FIG. 19 is a block diagram showing an egress demux, in accordance with some embodiments.
  • FIG. 20 is a call flow diagram showing a GPRS attach call flow, in accordance with some embodiments.
  • FIG. 21 is a call flow diagram showing a GPRS PDP context activation, in accordance with some embodiments.
  • FIG. 22 is a schematic network architecture diagram for various radio access technology core networks.
  • FIG. 23 is an enhanced eNodeB for performing the methods described herein, in accordance with some embodiments.
  • FIG. 24 is a coordinating server for providing services and performing methods as described herein, in accordance with some embodiments.
  • HNG HetNet Gateway
  • HNG makes this any-G hardware completely IP -based, so it can work with any IP -based backhaul.
  • providing backhaul can be extremely difficult and expensive when dealing with rural 2G markets; by enabling flexible backhaul via HNG, the CWS can work with satellite or microwave backhauls to drive down the cost.
  • HNG acts as a virtual machine by taking many of your essential network functions such as BSC, RNC, and SON and virtualizing them as VNFs on one low-cost server.
  • BSC basic system for Mobile communications
  • RNC Radio Network Controller
  • SON virtualizing them as VNFs on one low-cost server.
  • these components are now virtualized instead of coming as additional servers (which, by the way, is usually charged as additional costs billed ON TOP of what you were initially quoted), but having these elements as VNFs enables them to run on the same server in your data center or can even be deployed on small, ruggedized servers locally on-site.
  • VNF on HNG Another essential VNF on HNG is our real-time SON.
  • Parallel Wireless SON on HNG we can make network adjustments in real-time to any component of the network to greatly improve efficiencies. This allows us to instantly deploy our network, automatically manages interference between nodes, and manages the load on each cell to ensure the network is operating at maximum efficiency to ensure the optimal end-user experience.
  • This software-based approach also allows you to easily expand your network via virtualization.
  • self-optimization capabilities of HNG you can instantly deploy new base stations to expand your coverage footprint and HNG will seamlessly and automatically manage interference between neighbors. This helps to improve the enduser experience without requiring much human intervention to expand the network.
  • your subscribers adapt to newer technologies such as 3G or 4G, you can use the same software-upgradable features of HNG to update your CWS to provide dual -RAT coverage so you can provide 2G today, and when your subscribers are ready to move to 3G or 4G, provide 2G/3G or 2G/4G coverage to seamlessly migrate off of your GSM network. All this can be done without replacing the hardware on-site, which improves the time to upgrade while extending your investment.
  • upgrading these communities’ technologies you also empower them to improve their economies by enabling new services such as access to online education, mobile health, and eCommerce.
  • a 2G over IP system 100 is shown.
  • the system 100 includes a 2G CWS 101 in communication with a HNG 102 over a backhaul connection, which could be any of a variety of backhaul connections, e.g., fiber, microwave, cellular, etc. in some embodiments.
  • CWS 101 is coupled to both solar panel array 104 for power and satellite dish 103 for backhaul.
  • the CWS 101 contains a 2G BTS and Layer 1, in some embodiments, and the 2G BSC is provided by the HNG 102, in some embodiments.
  • the CWS 101 is also capable of two or more of: 2G/3G/4G/5G/Wi-Fi, in some embodiments, and the HNG 102 provides a gateway functionality to one or more cores of each radio access technology, in some embodiments, including MOCN and virtualization.
  • FIG. 2 shows a system 200 enabled to use either or both of satellite and microwave backhaul.
  • System 200 includes base station 201, with coverage area 204, which provides 2G and 3G, coupled to satellite backhaul 202 and a VS AT gateway 203 for managing the satellite backhaul. 2G and 3G UEs are shown in coverage area 204.
  • System 200 also includes 2G/4G base station 205, with coverage area 206, which covers 2G and 4G UEs.
  • Base station 205 uses microwave backhaul dish 207 and microwave router 208. Over the backhaul connection using dish 207, base station 205 has backhaul to HetNet Gateway 209.
  • Base station 201 is able to reach HNG 209 via satellite backhaul 202 and satellite 210. HNG 209 coordinates both base stations.
  • FIG. 3 shows than example architecture simplification 300.
  • the system includes a first CWS 301 and a second CWS 302, both in communication with HNG 303.
  • CWS 301 handles radio setup, performs time-delay measurements of received signals from the MS and some features like power management and frequency reallocation may be done with HNG coordination.
  • CWS 301 performs radio channel setup, including: translating (in some cases transrating/encoding/decoding/transcoding) the 13 Kbps voice channel used over the radio link to the standard 2G 64 Kbps channel; assigning and releasing frequencies and time slots for the mobile station (MS); frequency hopping control; and time and frequency synchronization, in some embodiments; in some embodiments other 2G BSC functionality is also provided at CWS 301; in other embodiments, certain 2G BTS functionality is also provided at CWS 301. In some embodiments, time-delay measurements of received signals from the mobile station and coordination of power management and frequency allocation with the HNG 303 may also be performed. Full software 2G support may be provided for the 2G PHY and 2G Layer 1 as well, in some embodiments.
  • 2G encryption may also be provided at CWS 301, in some embodiments.
  • CWS 301 is capable of performing these operations because the processing power envelope required to provide these functions is minimal compared to the processing power available for 3G and 4G RATs, in some embodiments.
  • the output of CWS 301 may be circuit-switched for compatibility with 2G and 3G cores, in some embodiments, in which case the A over IP interface may be used, or, in cases where voice capability at the core is provided by a packet-switched network, it may be packet- switched (for example, transformed to packet switched and delivered to a VoLTE or IMS or RTP or SIP network core), in some embodiments.
  • the output of CWS 301 is merged into a stream of IP packets for delivery over the common backhaul connection, whatever has been provided by the operator, including the various options described herein, in some embodiments.
  • HNG 303 performs SON based 0AM configuration, SON based power management, SON based frequency hopping, SON based channel allocation, handover, paging optimization, RTP localization (in the case of voice to RTP), perform traffic concentration to reduce the number of lines from the MSC and 0AM interface via Unimanage.
  • a over IP is used for existing 2G between the HNG 303 and the 2G core 310.
  • the core 310 may also include a 2G BSC, in some embodiments, or, the MSC may be a 3G core, or instead of an MSC a 4G or 5G core may be used, in some embodiments, with A over IP being used to backhaul a circuit switched signal to the MSC in the 3G core, or with another interface being used to backhaul a packet switched connection from HNG 303.
  • Various other core nodes 311 PSTN, ISDN, PSPDN, CSPDN are accessible via the core network 310.
  • a 2G/3G VLR 206, an EIR 307, and an HLR 308/AuC 309 may also be provided, in some embodiments, enabling the use of 2G using a 2G core, in some embodiments, or in other embodiments enabling the use of a 2G core using a 3G core.
  • an ALL G software platform 400 is shown.
  • Platform 400 is running at a location in the network between the RAN and the core network, and includes a core abstraction 401 layer, an analytics module 402, an orchestration module 403 including at least one optimization module 404 and a configuration module 405, a consolidation layer 406, and a RAN abstraction module 407. More configuration modules and optimization modules can be provided to provide services for the different Gs.
  • the consolidation layer 406 includes various different virtual network functions. By providing virtual network functions at the Parallel Wireless ALL G software platform, any base station with any G can be managed by the virtual network functions and not by the core network, thereby enabling effective RAN abstraction and core abstraction.
  • a virtual BSC handles 2G
  • a virtual RNC and Home nodeB gateway handle 3G
  • a home eNodeB gateway handles X2 gateway, and virtual eNodeB
  • a virtual EPC handle 4G/LTE
  • a virtual 5G core handles 5G
  • a TWAG/ePDG handle Wi-Fi
  • 5G- like features i.e. lower latency, e2e slicing, etc.
  • 5G is designed to have lower latency as one of its design goals, and consequently a 5G NR plus 5GCN will provide lower latency.
  • This lower latency is achieved partially by changing the transmit time interval (TTI)/RRC from 10ms to 1ms, directly reducing latency as part of the 5G radio standard; since 4G has a TTI of 10ms, single-digit latency is not achievable. However, today’s 4G networks have approximately 40 ms of latency. If the bottom limit of latency in 4G is 10 ms due to RRC, the remaining 30 ms, which may be from backhaul and non-optimized remote PGW, can be eliminated using the 5GCN, which the Parallel Wireless 5G Native Architecture is positioned to do using its abstraction layer.
  • PGW packet gateway
  • FIG. 5 is a diagram of a 2G BSS 500, in accordance with some embodiments BSS 500 includes a CWS 501 in communication with an HNG 502. Also shown is an MSC pool 503.
  • the software architecture of the 2G BSS is created such that it takes advantage of and is in-line with the current architectural decisions of the HNG and CWS products. Radio resource management related functions to be performed as close to the BTS as possible to utilize the available hardware at the BTS and thus free up HNG that can then handle more number of BTS nodes.
  • HNG completely manages the BTS and acts as a virtual BSC that can handle large number of BTS on its access side. Hence all the functions related to core network interface are handled by HNG while completely virtualizing the access side from the core network. This in turn helps in easy deployment and upgradation of the system at customer site.
  • FIG. 6 is a diagram of a 2G BSS 600.
  • Am MS 601 is shown, as is a CWS01, an HNG 602 and a SGSN 604.
  • the 2G BSS 600 has two primary responsibilities:
  • Managing the circuit switched (CS) path Part of BSC which is called as ‘RGW’ (remote gateway) would run inside the CWS (BTS). This will handle all the radio resource management functions.
  • the RGW will be designed such that it has ‘standardized’ interface towards the BTS software within the CWS, i.e. the communication between the BTS layers and RGW layers would use Abis over IP interface.
  • the advantage of this architecture is that standalone BTS software can then run with any third party BSC (without any assumption of interface). Also, in another way, we can port RGW software inside any available BTS to make the whole solution compatible with HNG.
  • the HNG would look like a core network node (SGSN). However, the HNG would act as PCU gateway and further talk to SGSN on its core network side while communicating with the PCUs present in every CWS on access side.
  • SGSN core network node
  • FIG,. 7 shows a call flow diagram 700 between the HNG 701 and the MSc 702.
  • This section documents the end to end call flows of the overall solution.
  • the call flows are divided into two sections - CS path (GSM) and PS path (GPRS). Handover will be supported in future phase of development.
  • GSM CS path
  • GPRS PS path
  • GSM Global System for Mobile Communications
  • HNG System Initialization - connecting to MSC
  • HNG would support multiple M3UA links to the peer for resiliency purposes. Also, we will support connecting to one or more MSC pools and MSC pool selection and MSC selection based on various criteria in future.
  • FIG. 8 shows a location update signaling flow 800.
  • FIG. 9 shows a signaling flow 900 for a Mobile Originating Mobile
  • FIG. 10 shows a signal flow 1000 for System Initialization.
  • the HNG acts as BSC towards the PS core network. It initializes the NS link.
  • the HNG would in turn generate a BVCI for the given CWS and will perform BSSGP RESET for that BVCI with the corresponding Cell-ID that is in use at the CWS.
  • the HNG would keep interacting with the PS core network to block and unblock the corresponding BVCI/Cell-ID.
  • FIG. 11 shows a signal flow 1100 for GPRS Attach and PDP Context Activation.
  • FIG. 12 shows a signal flow 1200 using the Short Message Service (SMS) for sending messages of limited size to and from GSM mobiles.
  • SMS Short Message Service
  • the provision of SMS makes use of a Service Centre, which acts as a store and forward center for short messages.
  • a GSM PLMN needs to support the transfer of short messages between Service Centers and mobiles.
  • Mobile originated messages shall be transported from an MS to a Service Centre. These may be destined for other mobile users, or for subscribers on a fixed network. Mobile terminated messages shall be transported from a Service Centre to a UE. [0079] These may be input to the Service Centre by other mobile users (via a mobile originated short message) or by a variety of other sources, e.g. speech, telex, or facsimile.
  • the SMS comprises 8 elements particular to the submission and reception of messages:
  • the short message service for GPRS shall be supported by a PDTCH.
  • SGSN is used in place of the MSC for SMS transfer over GPRS.
  • BSC to BTS link is proprietary.
  • a BSC on HNG will be identified by a set of TCP/IP endpoint addresses.
  • BSC/PCU will be identified by UDP endpoint above which NS layer runs.
  • UDP endpoint above which NS layer runs.
  • the circuit switched path will use SS7 over IP to talk to the core network. So, the identity of BSC will be a unique point code at SCCP layer. To reach this point code, it may utilize one or more M3UA links which will in turn have unique IP addresses at SCTP layer.
  • HNG On PS path, HNG is acting as BSC/PCU talking to SGSN(s). So, it will be identified by a ‘unique’ NSEI value at NS layer. NS layer will run over UDP/IP, so corresponding IP address/UDP port combination will be configured per BSC/PCU.
  • HNG as BSC would support one or more location area (LA)s. It may share the LA with other BSCs (on same HNG) or external BSCs.
  • LA location area
  • HNG as BSC/PCU would support one or more routing area (RA)s.
  • RA routing area
  • Each cell that BSC/PCU advertises towards core network requires one unique BVCI (BSSGP layer) +NSEI (NS layer) combination.
  • NSEI per BSC/PCU
  • vBSC virtual node
  • One or more ‘Virtual BSC’ instances will be configured on the HNG.
  • Each instance will be a separate virtual node on the HNG.
  • FIG, 13 shows a Virtual-BSC 1300 (hereinafter referred to as vBSC) that will co-exist with other types of virtual-nodes on the HNG (e.g. vENB, vRNC or vEPDG).
  • vBSC Virtual-BSC 1300
  • vBSC will have an ingress demux task - “BTSMgr”. This task will handle connections from all the BTS/CWS.
  • UEMGR task will be used as it is being done today for other virtual nodes. It will be used to create UE contexts for circuit-switched path.
  • vBSC will have an egress demux task - “BSCEgress”. This task will handle connections with circuit switched core network.
  • Fast path will be used to transfer RTP streams for voice path.
  • vBSC would provide new logging modules that can be individually controlled by the CLI.
  • vBSC would provide message level as well as virtual node level statistics that can be obtained via CLI and available as bulk stats files.
  • vBSC would generate and clear appropriate alarms for peer up/down events.
  • vPCU virtual node
  • One or more “Virtual PCU” instances will be configured on the HNG.
  • Each instance will be a separate virtual node on the HNG.
  • vPCU will co-exist with other types of virtual nodes on the HNG.
  • vPCU can be independently configured from vBSC and will not be dependent on existence of vBSC on the HNG.
  • vPCU will have an ingress demux task - ‘PCUIngress’. This task will handle connections from all the BTS/CWS.
  • UEMGR task will be used for creating and handling UE contexts.
  • vPCU will have an egress demux task - ‘PCUEgress’. This task will handle connections towards the packet switched core network, i.e. SGSN.
  • Fast path will be used to transfer data packets BSSGP data packets for a UE.
  • vPCU would provide new logging modules that can be individually controlled by the CLI.
  • vPCU would generate appropriate alarms upon peer up/down events.
  • vPCU would provide message level as well as virtual node level statistics that can be obtained via CLI and available as bulk stats files.
  • FIG. 14 shows an Ingress Demux - BTSMgr 1400.
  • BTSMgr would host the connections from all the BTS. It would perform the peer to peer signaling towards each BTS. All UE specific signaling would be transferred to UEMGR which would be selected on round robin basis using common framework available.
  • BTSMgr would be started up by Configmgr.
  • One instance of BTSMgr would be started for every unique endpoint found per virtual network.
  • BTSMgr tasks that listen on different endpoints.
  • Phase-1 we will divide the load between the two tasks by providing individual BTS with different destination endpoint of vBSC in round robin fashion.
  • TCP proxy in front of these tasks to divide the incoming connections between them.
  • This task would host the connections towards the CS core network elements, e.g. MSC. It would host the SS7 endpoint of the BSC.
  • this task Only one instance of this task would be used per vBSC. All the node specific procedures towards the peers would be handled locally by this task. For UE specific messages, this task would transfer the message to respective UEMGR where the context of the UE is created or present. This task would follow the same redundancy model as VRNC virtual node on HNG, i.e. it will be possible to create multiple M3UA links towards the peers and the links can be configured to be distributed across the HNG pair. This ensures that failure of one HNG or this task does not affect the availability of vBSC from MSC’s point of view because at least one M3UA link will always be available.
  • UEMGR would host the MS/UE context for the vBSC. Every UE context is identified by a unique call-id on the HNG. It is the responsibility of the demux task to request for a new call context on the UEMGR. With respect to ingress demux task (BTSMgr):
  • TMSI/IMSI of the subscriber is unknown, then it will select a UEMGR on round-robin basis and ask for creation of UE context.
  • This message would be received when UE is trying to perform a CM/MM procedure after latching on to the BTS, e.g. Location Update, CS Call/SMS (originating), CS Call/SMS (terminating via paging response) or Detach
  • Each UE context would maintain a FSM and manage the RTP streams to be used for CS call connection.
  • UEMGR would create RTP flows in the fast path for transfer of RTP data of ongoing calls directly through fast path.
  • UEMGR would only process the control signaling events for the UEs.
  • HNG infrastructure fast path component would be used for transfer of RTP streams during CS calls.
  • vBSC would have access side RTP endpoint(s) which will be used to exchange RTP traffic with all BTS.
  • vBSC would have core side RTP endpoint(s) which will be used to exchange RTP traffic with all the MGW s. Note that vBSC will not allow BTS to directly talk to MGW endpoints for transfer of any data. For a given RTP stream, vBSC would act like a UDP proxy to transfer the data.
  • a Location Update call flow 1500 is shown in FIG. 15
  • a Mobile Originating call flow 1600 is shown in FIG. 16.
  • a Short Message Service Mobile Originating call flow 1700 is shown in FIG. 17.
  • a PCU Ingress application 1800 is shown in FIG. 18. This task would host the Gb interface towards the CWS/BTS. It would host the Gb protocol stack. All the node level functionality of Gb protocol will be executed between CWS and this task. All the UE level messaging will be appropriately forwarded to UEMGR for further processing. So, BSSGP layer node level messages and NS layer node level messages will be handled in this task. NS layer runs over UDP and IP, hence this task would open a UDP socket per NS link. Note that this task would only receive control signaling traffic from CWS.
  • a PCU Egress application 1900 is shown in FIG. 19. This task is similar to ingress demux, but hosts the Gb connection towards the SGSN or packet core network. It can connect to one or more SGSNs and SGSN selection would also be done by this for a UE.
  • Core network could connected either be in MOCN configuration, GWCN configuration or DCN (Dedicated core network) configuration.
  • Gb protocol stack would be hosted that will talk to core networks.
  • UEMGR would host the UE contexts of the vPCU.
  • the UE context would be created when the first uplink-unitdata data message (containing certain GMM/SM/SMS message types) is received from the CWS that contains either a foreign/random TLLI or a unique TLLI which has not been seen earlier from this particular CWS.
  • UEMGR would have to scan the GMM messages for the call and delete the context at appropriate time. There is no specific call deletion trigger that will come from either access side or core side network. Typically, a BSS frees up the context after a timeout (when it does not at all check the signaling messages being exchanged).
  • UEMGR would install the flow in the fast path for every UE so that the data packets coming in from access side can traverse to core side without leaving the fastpath and same for vice versa. It will install the flow based on the TLLI of the UE.
  • the vPCU would install fastpath flows for every UE.
  • the flow would be based on UE’s TLLI. Since TLLI can be assumed to be unique only with a routing area, so, the TLLI as key alone is not sufficient.
  • the uplink flow will thus have to have key of Local-TLLI + BVCI of CWS. Since one CWS as a cell would be part of one routing-area, this key combination will be unique.
  • the key would be TLLI + BVCI of the cell for which the data is arriving.
  • the flow will be such that it handles only the data packets of the subscriber. All control signaling packets will be passed on to the corresponding demux task. Since we will use separate BVCIs to identify the same cell on access/vs core network, the fast path flow would alter the packet accordingly before forwarding it.
  • a GPRS Attach call flow 2000 is shown in FIG. 20.
  • a GPRS PDP Context Activation call flow 2100 is shown in FIG. 21
  • FIG. 22 is a schematic network architecture diagram for 3G and other-G prior art networks.
  • the diagram shows a plurality of “Gs,” including 2G, 3G, 4G, 5G and WiFi.
  • 2G is represented by GERAN 501, which includes a 2G device 2201a, BTS 2201b, and BSC 2201c.
  • 3G is represented by UTRAN 2202, which includes a 3G UE 2202a, nodeB 2202b, RNC 2202c, and femto gateway (FGW, which in 3GPP namespace is also known as a Home nodeB Gateway or HNBGW) 2202d.
  • FGW femto gateway
  • Wi-Fi 4G is represented by EUTRAN or E-RAN 2203, which includes an LTE UE 2203a and LTE eNodeB 2203b.
  • Wi-Fi is represented by Wi-Fi access network 2204, which includes a trusted Wi-Fi access point 2204c and an untrusted Wi-Fi access point 2204d.
  • the Wi-Fi devices 2204a and 2204b may access either AP 2204c or 2204d.
  • each “G” has a core network.
  • 2G circuit core network 2205 includes a 2G MSC/VLR;
  • 2G/3G packet core network 2206 includes an SGSN/GGSN (for EDGE or UMTS packet traffic);
  • 3G circuit core 2207 includes a 3G MSC/VLR;
  • 4G circuit core 2208 includes an evolved packet core (EPC); and in some embodiments the Wi-Fi access network may be connected via an ePDG/TTG using S2a/S2b.
  • EPC evolved packet core
  • Each of these nodes are connected via a number of different protocols and interfaces, as shown, to other, non-“G”-specific network nodes, such as the SCP 2230, the SMSC 2231, PCRF 2232, HLR/HSS 2233, Authentication, Authorization, and Accounting server (AAA) 2234, and IP Multimedia Subsystem (IMS) 2235.
  • An HeMS/AAA 2236 is present in some cases for use by the 3G UTRAN.
  • the diagram is used to indicate schematically the basic functions of each network as known to one of skill in the art, and is not intended to be exhaustive.
  • 22G core 2217 is shown using a single interface to 22G access 2216, although in some cases 22G access can be supported using dual connectivity or via a non-standalone deployment architecture.
  • the RANs 2201, 2202, 2203, 2204 and 2236 rely on specialized core networks 2205, 2206, 2207, 2208, 2209, 2237 but share essential management databases 2230, 2231, 2232, 2233, 2234, 2235, 2238.
  • a BSC 2201c is required for Abis compatibility with BTS 2201b, while for the 3G UTRAN, an RNC 2202c is required for lub compatibility and an FGW 2202d is required for luh compatibility.
  • These core network functions are separate because each RAT uses different methods and techniques.
  • On the right side of the diagram are disparate functions that are shared by each of the separate RAT core networks. These shared functions include, e.g., PCRF policy functions, AAA authentication functions, and the like. Letters on the lines indicate well-defined interfaces and protocols for communication between the identified nodes.
  • the system may include 5G equipment.
  • 5G networks are digital cellular networks, in which the service area covered by providers is divided into a collection of small geographical areas called cells. Analog signals representing sounds and images are digitized in the phone, converted by an analog to digital converter and transmitted as a stream of bits. All the 5G wireless devices in a cell communicate by radio waves with a local antenna array and low power automated transceiver (transmitter and receiver) in the cell, over frequency channels assigned by the transceiver from a common pool of frequencies, which are reused in geographically separated cells.
  • the local antennas are connected with the telephone network and the Internet by a high bandwidth optical fiber or wireless backhaul connection.
  • 5G uses millimeter waves which have shorter range than microwaves, therefore the cells are limited to smaller size.
  • Millimeter wave antennas are smaller than the large antennas used in previous cellular networks. They are only a few inches (several centimeters) long.
  • massive MIMO multiple-input multiple-output
  • Each cell will have multiple antennas communicating with the wireless device, received by multiple antennas in the device, thus multiple bitstreams of data will be transmitted simultaneously, in parallel.
  • beamforming the base station computer will continuously calculate the best route for radio waves to reach each wireless device, and will organize multiple antennas to work together as phased arrays to create beams of millimeter waves to reach the device.
  • FIG. 23 shows is an enhanced eNodeB for performing the methods described herein, in accordance with some embodiments.
  • eNodeB 2300 may include processor 2302, processor memory 2304 in communication with the processor, baseband processor 2306, and baseband processor memory 2308 in communication with the baseband processor.
  • Mesh network node 2300 may also include first radio transceiver 2312 and second radio transceiver 2314, internal universal serial bus (USB) port 2316, and subscriber information module card (SIM card) 2318 coupled to USB port 2316.
  • the second radio transceiver 2314 itself may be coupled to USB port 2316, and communications from the baseband processor may be passed through USB port 2316.
  • the second radio transceiver may be used for wirelessly backhauling eNodeB 2300.
  • Processor 2302 and baseband processor 2306 are in communication with one another.
  • Processor 2302 may perform routing functions, and may determine if/when a switch in network configuration is needed.
  • Baseband processor 2306 may generate and receive radio signals for both radio transceivers 2312 and 2314, based on instructions from processor 2302.
  • processors 2302 and 2306 may be on the same physical logic board. In other embodiments, they may be on separate logic boards.
  • Processor 2302 may identify the appropriate network configuration, and may perform routing of packets from one network interface to another accordingly.
  • Processor 2302 may use memory 2304, in particular to store a routing table to be used for routing packets.
  • Baseband processor 2306 may perform operations to generate the radio frequency signals for transmission or retransmission by both transceivers 2310 and 2312.
  • Baseband processor 2306 may also perform operations to decode signals received by transceivers 2312 and 2314.
  • Baseband processor 2306 may use memory 2308 to perform these tasks.
  • the first radio transceiver 2312 may be a radio transceiver capable of providing LTE eNodeB functionality, and may be capable of higher power and multichannel OFDMA.
  • the second radio transceiver 2314 may be a radio transceiver capable of providing LTE UE functionality. Both transceivers 2312 and 2314 may be capable of receiving and transmitting on one or more LTE bands. In some embodiments, either or both of transceivers 2312 and 2314 may be capable of providing both LTE eNodeB and LTE UE functionality.
  • Transceiver 2312 may be coupled to processor 2302 via a Peripheral Component Interconnect-Express (PCI-E) bus, and/or via a daughtercard.
  • PCI-E Peripheral Component Interconnect-Express
  • transceiver 2314 is for providing LTE UE functionality, in effect emulating a user equipment, it may be connected via the same or different PCI-E bus, or by a USB bus, and may also be coupled to SIM card 2318.
  • First transceiver 2312 may be coupled to first radio frequency (RF) chain (filter, amplifier, antenna) 2322, and second transceiver 2314 may be coupled to second RF chain (filter, amplifier, antenna) 2324.
  • RF radio frequency
  • SIM card 2318 may provide information required for authenticating the simulated UE to the evolved packet core (EPC). When no access to an operator EPC is available, a local EPC may be used, or another local EPC on the network may be used. This information may be stored within the SIM card, and may include one or more of an international mobile equipment identity (IMEI), international mobile subscriber identity (IMSI), or other parameter needed to identify a UE. Special parameters may also be stored in the SIM card or provided by the processor during processing to identify to a target eNodeB that device 2300 is not an ordinary UE but instead is a special UE for providing backhaul to device 2300.
  • IMEI international mobile equipment identity
  • IMSI international mobile subscriber identity
  • Special parameters may also be stored in the SIM card or provided by the processor during processing to identify to a target eNodeB that device 2300 is not an ordinary UE but instead is a special UE for providing backhaul to device 2300.
  • Wired backhaul or wireless backhaul may be used.
  • Wired backhaul may be an Ethernet-based backhaul (including Gigabit Ethernet), or a fiber-optic backhaul connection, or a cable-based backhaul connection, in some embodiments.
  • wireless backhaul may be provided in addition to wireless transceivers 2312 and 2314, which may be Wi-Fi 802.1 la/b/g/n/ac/ad/ah, Bluetooth, ZigBee, microwave (including line-of-sight microwave), or another wireless backhaul connection.
  • a GPS module 2330 may also be included, and may be in communication with a GPS antenna 2332 for providing GPS coordinates, as described herein. When mounted in a vehicle, the GPS antenna may be located on the exterior of the vehicle pointing upward, for receiving signals from overhead without being blocked by the bulk of the vehicle or the skin of the vehicle.
  • ANR Automatic neighbor relations
  • a home eNodeB may also be included, such as a home eNodeB, a local gateway (LGW), a self-organizing network (SON) module, or another module. Additional radio amplifiers, radio transceivers and/or wired network connections may also be included.
  • LGW local gateway
  • SON self-organizing network
  • FIG. 24 shows a coordinating server for providing services and performing methods as described herein, in accordance with some embodiments.
  • Coordinating server 2400 includes processor 2402 and memory 2404, which are configured to provide the functions described herein.
  • radio access network coordination/routing (RAN Coordination and routing) module 2406 including ANR module 2406a, RAN configuration module 2408, and RAN proxying module 2410.
  • the ANR module 2406a may perform the ANR tracking, PCI disambiguation, ECGI requesting, and GPS coalescing and tracking as described herein, in coordination with RAN coordination module 2406 (e.g., for requesting ECGIs, etc.).
  • coordinating server 2400 may coordinate multiple RANs using coordination module 2406.
  • coordination server may also provide proxying, routing virtualization and RAN virtualization, via modules 2410 and 2408.
  • a downstream network interface 2412 is provided for interfacing with the RANs, which may be a radio interface (e.g., LEE), and an upstream network interface 2414 is provided for interfacing with the core network, which may be either a radio interface (e.g., LTE) or a wired interface (e.g., Ethernet).
  • Coordinator 2400 includes local evolved packet core (EPC) module 2420, for authenticating users, storing and caching priority profile information, and performing other EPC-dependent functions when no backhaul link is available.
  • EPC 2420 may include local HSS 2422, local MME 2424, local SGW 2426, and local PGW 2428, as well as other modules.
  • Local EPC 2420 may incorporate these modules as software modules, processes, or containers.
  • Local EPC 2420 may alternatively incorporate these modules as a small number of monolithic software processes.
  • Modules 2406, 2408, 2410 and local EPC 2420 may each run on processor 2402 or on another processor, or may be located within another device.
  • a mesh node may be an eNodeB.
  • An eNodeB may be in communication with the cloud coordination server via an X2 protocol connection, or another connection.
  • the eNodeB may perform inter-cell coordination via the cloud communication server, when other cells are in communication with the cloud coordination server.
  • the eNodeB may communicate with the cloud coordination server to determine whether the UE has the ability to support a handover to Wi-Fi, e.g., in a heterogeneous network.
  • LTE Long Term Evolution
  • MME Mobility Management Entity
  • any other node in the core network could be managed in much the same way or in an equivalent or analogous way, for example, multiple connections to 4G EPC PGWs or SGWs, or any other node for any other RAT, could be periodically evaluated for health and otherwise monitored, and the other aspects of the present disclosure could be made to apply, in a way that would be understood by one having skill in the art.
  • a coordination server such as the Parallel Wireless HetNet Gateway, which performs virtualization of the RAN towards the core and vice versa, so that the core functions may be statefully proxied through the coordination server to enable the RAN to have reduced complexity.
  • At least four scenarios are described: (1) the selection of an MME or core node at the base station; (2) the selection of an MME or core node at a coordinating server such as a virtual radio network controller gateway (VRNCGW); (3) the selection of an MME or core node at the base station that is connected to a 5G-capable core network (either a 5G core network in a 5G standalone configuration, or a 4G core network in 5G non-standalone configuration); (4) the selection of an MME or core node at a coordinating server that is connected to a 5G-capable core network (either 5G SA or NSA).
  • a coordinating server such as a virtual radio network controller gateway (VRNCGW)
  • VRNCGW virtual radio network controller gateway
  • the core network RAT is obscured or virtualized towards the RAN such that the coordination server and not the base station is performing the functions described herein, e.g., the health management functions, to ensure that the RAN is always connected to an appropriate core network node.
  • the functions described herein e.g., the health management functions
  • Different protocols other than SI AP, or the same protocol, could be used, in some embodiments.
  • the software needed for implementing the methods and procedures described herein may be implemented in a high level procedural or an object- oriented language such as C, C++, C#, Python, Java, or Perl.
  • the software may also be implemented in assembly language if desired.
  • Packet processing implemented in a network device can include any processing determined by the context. For example, packet processing may involve high-level data link control (HDLC) framing, header compression, and/or encryption.
  • HDLC high-level data link control
  • software that, when executed, causes a device to perform the methods described herein may be stored on a computer- readable medium such as read-only memory (ROM), programmable-read-only memory (PROM), electrically erasable programmable-read-only memory (EEPROM), flash memory, or a magnetic disk that is readable by a general or special purpose-processing unit to perform the processes described in this document.
  • the processors can include any microprocessor (single or multiple core), system on chip (SoC), microcontroller, digital signal processor (DSP), graphics processing unit (GPU), or any other integrated circuit capable of processing instructions such as an x86 microprocessor.
  • the radio transceivers described herein may be base stations compatible with a Long Term Evolution (LTE) radio transmission protocol or air interface.
  • LTE-compatible base stations may be eNodeBs.
  • the base stations may also support other air interfaces, such as UMTS/HSPA, CDMA/CDMA2000, GSM/EDGE, GPRS, EVDO, 2G, 3G, 5G, TDD, or other air interfaces used for mobile telephony.
  • the base stations described herein may support Wi-Fi air interfaces, which may include one or more of IEEE 802.1 la/b/g/n/ac/af/p/h.
  • the base stations described herein may support IEEE 802.16 (WiMAX), to LTE transmissions in unlicensed frequency bands (e.g., LTE-U, Licensed Access or LA- LTE), to LTE transmissions using dynamic spectrum access (DSA), to radio transceivers for ZigBee, Bluetooth, or other radio frequency protocols, or other air interfaces.
  • WiMAX IEEE 802.16
  • LTE-U LTE transmissions in unlicensed frequency bands
  • DSA dynamic spectrum access
  • ZigBee ZigBee
  • Bluetooth Bluetooth
  • the protocols described herein have largely been adopted by the 3GPP as a standard for the upcoming 5G network technology as well, in particular for interfacing with 4G/LTE technology.
  • X2 is used in both 4G and 5G and is also complemented by 5G-specific standard protocols called Xn.
  • the 5G standard includes two phases, non- standalone (which will coexist with 4G devices and networks) and standalone, and also includes specifications for dual connectivity of UEs to both LTE and NR (“New Radio”) 5G radio access networks.
  • the inter-base station protocol between an LTE eNB and a 5G gNB is called Xx.
  • the specifications of the Xn and Xx protocol are understood to be known to those of skill in the art and are hereby incorporated by reference dated as of the priority date of this application.
  • EPC Evolved Packet Core
  • MME mobility management entity
  • S-GW serving gateway
  • MME/S-GW mobility management entity
  • MME/S-GW mobility management gateway
  • the present disclosure contemplates a gateway node, variously described as a gateway, HetNet Gateway, multi- RAT gateway, LTE Access Controller, radio access network controller, aggregating gateway, cloud coordination server, coordinating gateway, or coordination cloud, in a gateway role and position between one or more core networks (including multiple operator core networks and core networks of heterogeneous RATs) and the radio access network (RAN).
  • This gateway node may also provide a gateway role for the X2 protocol or other protocols among a series of base stations.
  • the gateway node may also be a security gateway, for example, a TWAG or ePDG.
  • the RAN shown is for use at least with an evolved universal mobile telecommunications system terrestrial radio access network (E-UTRAN) for 4G/LTE, and for 5G, and with any other combination of RATs, and is shown with multiple included base stations, which may be eNBs or may include regular eNBs, femto cells, small cells, virtual cells, virtualized cells (i.e., real cells behind a virtualization gateway), or other cellular base stations, including 3G base stations and 5G base stations (gNBs), or base stations that provide multi-RAT access in a single device, depending on context.
  • E-UTRAN evolved universal mobile telecommunications system terrestrial radio access network
  • base stations which may be eNBs or may include regular eNBs, femto cells, small cells, virtual cells, virtualized cells (i.e., real cells behind a virtualization gateway), or other cellular base stations, including 3G base stations and 5G base stations (gNBs), or base stations that provide multi-RAT access in a single device,
  • Wi-Fi may be provided as a RAT, either on its own or as a component of a cellular access network via a trusted wireless access gateway (TWAG), evolved packet data network gateway (ePDG) or other gateway, which may be the same as the coordinating gateway described hereinabove.
  • TWAG trusted wireless access gateway
  • ePDG evolved packet data network gateway
  • the word “X2” herein may be understood to include X2 or also Xn or Xx, as appropriate.
  • the gateway described herein is understood to be able to be used as a proxy, gateway, B2BUA, interworking node, interoperability node, etc. as described herein for and between X2, Xn, and/or Xx, as appropriate, as well as for any other protocol and/or any other communications between an LTE eNB, a 5G gNB (either NR, standalone or non- standalone).
  • the gateway described herein is understood to be suitable for providing a stateful proxy that models capabilities of dual connectivity-capable handsets for when such handsets are connected to any combination of eNBs and gNBs.
  • the gateway described herein may perform stateful interworking for master cell group (MCG), secondary cell group (SCG), other dual -connectivity scenarios, or single-connectivity scenarios.
  • the base stations described herein may be compatible with a Long Term Evolution (LTE) radio transmission protocol, or another air interface.
  • LTE-compatible base stations may be eNodeBs, or may be gNodeBs, or may be hybrid base stations supporting multiple technologies and may have integration across multiple cellular network generations such as steering, memory sharing, data structure sharing, shared connections to core network nodes, etc.
  • the base stations may also support other air interfaces, such as UMTS/HSPA, CDMA/CDMA2000, GSM/EDGE, GPRS, EVDO, other 3G/2G, legacy TDD, 5G, or other air interfaces used for mobile telephony.
  • the base stations described herein may support Wi-Fi air interfaces, which may include one of 802.11a/b/g/n/ac/ad/af/ah. In some embodiments, the base stations described herein may support 802.16 (WiMAX), or other air interfaces. In some embodiments, the base stations described herein may provide access to land mobile radio (LMR)-associated radio frequency bands. In some embodiments, the base stations described herein may also support more than one of the above radio frequency protocols, and may also support transmit power adjustments for some or all of the radio frequency protocols supported.
  • LMR land mobile radio
  • a mesh node may be an eNodeB.
  • An eNodeB may be in communication with the cloud coordination server via an X2 protocol connection, or another connection.
  • the eNodeB may perform inter-cell coordination via the cloud communication server, when other cells are in communication with the cloud coordination server.
  • the eNodeB may communicate with the cloud coordination server to determine whether the UE has the ability to support a handover to Wi-Fi, e.g., in a heterogeneous network.
  • LTE Long Term Evolution
  • MME Mobility Management Entity
  • any other node in the core network could be managed in much the same way or in an equivalent or analogous way, for example, multiple connections to 4G EPC PGWs or SGWs, or any other node for any other RAT, could be periodically evaluated for health and otherwise monitored, and the other aspects of the present disclosure could be made to apply, in a way that would be understood by one having skill in the art.
  • a coordination server such as the Parallel Wireless HetNet Gateway, which performs virtualization of the RAN towards the core and vice versa, so that the core functions may be statefully proxied through the coordination server to enable the RAN to have reduced complexity.
  • At least four scenarios are described: (1) the selection of an MME or core node at the base station; (2) the selection of an MME or core node at a coordinating server such as a virtual radio network controller gateway (VRNCGW); (3) the selection of an MME or core node at the base station that is connected to a 5G-capable core network (either a 5G core network in a 5G standalone configuration, or a 4G core network in 5G non-standalone configuration); (4) the selection of an MME or core node at a coordinating server that is connected to a 5G-capable core network (either 5G SA or NSA).
  • a coordinating server such as a virtual radio network controller gateway (VRNCGW)
  • VRNCGW virtual radio network controller gateway
  • the core network RAT is obscured or virtualized towards the RAN such that the coordination server and not the base station is performing the functions described herein, e.g., the health management functions, to ensure that the RAN is always connected to an appropriate core network node.
  • Different protocols other than S1AP, or the same protocol, could be used, in some embodiments.
  • the software needed for implementing the methods and procedures described herein may be implemented in a high level procedural or an object- oriented language such as C, C++, C#, Python, Java, or Perl.
  • the software may also be implemented in assembly language if desired.
  • Packet processing implemented in a network device can include any processing determined by the context. For example, packet processing may involve high-level data link control (HDLC) framing, header compression, and/or encryption.
  • HDLC high-level data link control
  • software that, when executed, causes a device to perform the methods described herein may be stored on a computer- readable medium such as read-only memory (ROM), programmable-read-only memory (PROM), electrically erasable programmable-read-only memory (EEPROM), flash memory, or a magnetic disk that is readable by a general or special purpose-processing unit to perform the processes described in this document.
  • the processors can include any microprocessor (single or multiple core), system on chip (SoC), microcontroller, digital signal processor (DSP), graphics processing unit (GPU), or any other integrated circuit capable of processing instructions such as an x86 microprocessor.
  • the radio transceivers described herein may be base stations compatible with a 5G, or Long Term Evolution (LTE) radio transmission protocol or air interface.
  • LTE-compatible base stations may be eNodeBs.
  • the base stations may also support other air interfaces, such as UMTS/HSPA, CDMA/CDMA2000, GSM/EDGE, GPRS, EVDO, 2G, 3G, 5G, TDD, or other air interfaces used for mobile telephony.
  • UMTS/HSPA Code Division Multiple Access
  • CDMA/CDMA2000 Code Division Multiple Access 2000
  • GSM/EDGE Global System for Mobile communications
  • GPRS Packet Radio Service
  • EVDO EVDO
  • 2G 3G
  • 5G 5G
  • TDD Time Division Duplex
  • a 5G base station is also contemplated, in some cases as a multi-RAT base station.
  • a 4G core is contemplated
  • a 5G SA or NSA core is also contemplated, including MOCN and
  • the base stations described herein may support Wi-Fi air interfaces, which may include one or more of IEEE 802.1 la/b/g/n/ac/af/p/h.
  • the base stations described herein may support IEEE 802.16 (WiMAX), to LTE transmissions in unlicensed frequency bands (e.g., LTE-U, Licensed Access or LA- LTE), to LTE transmissions using dynamic spectrum access (DSA), to radio transceivers for ZigBee, Bluetooth, or other radio frequency protocols, or other air interfaces.
  • WiMAX IEEE 802.16
  • LTE-U LTE transmissions in unlicensed frequency bands
  • DSA dynamic spectrum access
  • ZigBee ZigBee
  • Bluetooth Bluetooth

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne des systèmes, des procédés et un logiciel informatique pour la fourniture d'une machine virtuelle pour des réseaux 2G, la machine virtuelle fournissant une pluralité de fonctions réseau virtualisées (VNF).
EP21867541.1A 2020-09-08 2021-09-08 Architecture de système de passerelle hetnet 2g Pending EP4211987A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/014,346 US20210227405A1 (en) 2019-02-25 2020-09-08 2G HetNet Gateway System Architecture
PCT/US2021/049517 WO2022056034A1 (fr) 2020-09-08 2021-09-08 Architecture de système de passerelle hetnet 2g

Publications (1)

Publication Number Publication Date
EP4211987A1 true EP4211987A1 (fr) 2023-07-19

Family

ID=80629881

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21867541.1A Pending EP4211987A1 (fr) 2020-09-08 2021-09-08 Architecture de système de passerelle hetnet 2g

Country Status (2)

Country Link
EP (1) EP4211987A1 (fr)
WO (1) WO2022056034A1 (fr)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015051845A1 (fr) * 2013-10-10 2015-04-16 Telefonaktiebolaget L M Ericsson (Publ) Pool de passerelles de réseau
EP3498043A4 (fr) * 2016-08-15 2020-08-05 Parallel Wireless Inc. Mandataire de convergence pour virtualisation de réseau central
US10932164B2 (en) * 2017-01-27 2021-02-23 Parallel Wireless, Inc. CDMA/EVDO virtualization
US10187928B2 (en) * 2017-03-07 2019-01-22 Indian Institute Of Technology Bombay Methods and systems for controlling a SDN-based multi-RAT communication network
WO2019227107A1 (fr) * 2018-05-25 2019-11-28 Parallel Wireless, Inc. Architecture d'interopérabilité 5g
US20200275521A1 (en) * 2019-02-25 2020-08-27 Parallel Wireless, Inc. 2G Over IP Architecture

Also Published As

Publication number Publication date
WO2022056034A1 (fr) 2022-03-17

Similar Documents

Publication Publication Date Title
US20210045193A1 (en) 5G/4G/3G/2G Cloud-Native OpenRAN Architecture
US11129240B2 (en) 5G interoperability architecture
US20210045011A1 (en) OpenRAN and Virtualized Baseband Radio Unit
US11924899B2 (en) Multipath TCP with mesh access
US20240031794A1 (en) Support for CUPS PFCP Session at UE Level for Serving Gateway
US20220330354A1 (en) Mesh Connectivity Establishment
US11483790B2 (en) Multiple context issue for single UE in the network
US20240090082A1 (en) Hybrid Base Station and RRH
US11470505B2 (en) Support for linking of packet detection rules (PDR) for optimizing throughput of combined serving gateway (SGW)/packet gateway (PGW) architecture
US20210227405A1 (en) 2G HetNet Gateway System Architecture
US20210084714A1 (en) 4G/5G Core Interworking
US11910303B2 (en) OpenRAN solution suite
US20210076259A1 (en) Real-Time Any-G SON
US20200275521A1 (en) 2G Over IP Architecture
EP4211987A1 (fr) Architecture de système de passerelle hetnet 2g
US20230030933A1 (en) Optimized S1-X2 Handovers
US20230008393A1 (en) X2GW Multi-Cell Support
US20230043184A1 (en) ENDC Connectivity with Virtualized eNBs
US20230205752A1 (en) Internal Service/Function Discovery
US20230055306A1 (en) 4G/5G Open RAN CU-UP High Availability Solution
US20220400424A1 (en) 4G-5G Open RAN User Plane Path
US20230379731A1 (en) Enhanced OpenRAN-MEC Info Exchange Solution
US20230229428A1 (en) Telecom Microservice Rolling Upgrades
US11973822B2 (en) Method for handling of an inbound SCTP packet at an SCTP load balancer and tunneling methodology
US20210250839A1 (en) FAR ID Provisioning During Dedicated Bearer Creation

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230327

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR