System and method for supporting low mobility devices in next generation wireless networks

Abstract

A method and apparatus for addressing different types of mobility of a wireless transmit / receive unit (WTRU) in a network. A radio access network (RAN) may send a configuration information request including a device ID, a service ID, and a RAN address to a gateway device. Once the RAN receives the configuration information including a forwarding table from the gateway device, the RAN may prepare to receive non-IP data including a routing label from the WTRU. The routing label may be based on the device ID and the service ID of the WTRU. The RAN may transmit the non-IP data received from the WTRU to the gateway device based on the routing label and the forwarding table and over a routing path, where the non-IP data will be forwarded to its destination, such as another WTRU or an application server.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 201780022554.3, entitled “System and Method for Supporting Low Mobility Devices in Next Generation Wireless Networks”, filed on March 30, 2017.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of 62 / 315,398, filed March 30, 2016, the contents of which are incorporated herein by reference. Background Art

[0004] In wireless communications, a wireless transmit / receive unit (WTRU) may travel from one radio access network (RAN) to another. Conventional systems may not adequately address the varying degrees of WTRU mobility and the consequences of such mobility. For example, the WTRU's mobility may be stationary or it may move minimally from time to time. Conventional systems may not adequately address such mobility in the design, operation, and configuration of wireless networks. Summary of the invention

[0005] Disclosed is a method and system for supporting non-IP data routing for low-mobility devices in a next generation wireless network. The data routing includes performing non-IP data routing inside a 3GPP network and performing IP data routing outside the 3GPP network. The data routing is performed in an ingress / egress GW located at the network boundary, wherein the ingress / egress GW converts between non-IP data and IP packets. The egress GW converts non-IP data into IP packets by assigning a temporary device IP address to the device with the help of a GW controller, and maintains a mapping between the device ID and the temporary device IP. In the downlink, the ingress GW converts the IP packet into non-IP data by looking up the device ID of the device using the stored mapping information. Inside the 3GPP network, the routing path is established using SDN-based technology, and the device ID / service ID combination is used as a routing tag.

[0006] In addition, the system and apparatus address different types of mobility of wireless transmit / receive units (WTRUs) in a network. A radio access network (RAN) may send a configuration information request including a device ID, a service ID, and a RAN address of the WTRU to a gateway device. Once the RAN receives the configuration information including a forwarding table from the gateway device, the RAN may prepare to receive non-IP data including a routing tag from the WTRU. The routing tag may be based on the device ID and the service ID of the WTRU. The RAN may transmit the non-IP data received from the WTRU to the gateway device via a routing path based on the routing tag and the forwarding table, where the non-IP data will be forwarded to its destination, such as another WTRU or an application server. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which:

[0008] Figure 1A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented;

[0009] Figure 1B Yes, you can Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) used within the communication system shown;

[0010] Figure 1C Yes, you can Figure 1A A system diagram of an example radio access network and an example core network used within the communication system shown;

[0011] Figure 2 is a system diagram of an example architecture for supporting GTP-based mobility in an LTE EPC;

[0012] Figure 3 is a system diagram of an example architecture for supporting non-IP data routing;

[0013] Figure 4 shows an example of a high-level data protocol stack for supporting a non-IP data routing architecture;

[0014] Figure 5 shows an example of a protocol stack for non-IP data routing;

[0015] Figure 6 An exemplary method for selecting different egress GWs for different non-IP data services is shown;

[0016] Figure 7 An example of the Non-IP Data Protocol / Format (NIDP) data format is shown;

[0017] Figure 8 An exemplary method for performing incoming non-IP data routing processing is shown; and

[0018] Fig. 9 An exemplary method for performing fast routing path modification is shown. DETAILED DESCRIPTION

[0019] Figure 1A 1 is a diagram of an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 enables multiple wireless users to access these contents by sharing system resources including wireless bandwidth. As an example, the communication system 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), and single carrier FDMA (SC-FDMA), etc.

[0020] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors, consumer electronic devices, Internet of Things devices, sensors, servers, and computer collections (e.g., for cloud computing), among others.

[0021] The communication system 100 may also include a base station 114a and a base station 114b. Each base station 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., the core network 106, the Internet 110, and / or other networks 112) by wirelessly interfacing with at least one WTRU 102a, 102b, 102c, 102d. By way of example, the base stations 114a, 114b may be base transceiver stations (BTS), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, site controllers, access points (APs), wireless routers, and the like. Although each base station 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0022] The base station 114a may be part of a radio access network (RAN) 104, and the RAN may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals within a specific geographic area called a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In another embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology, and thus may use multiple transceivers for each sector of the cell.

[0023] The base stations 114a, 114b may communicate with one or more WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0024] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. As an example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0025] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A).

[0026] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio access technologies such as IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0027] As an example, Figure 1AThe base station 114b in the example may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any appropriate RAT to facilitate wireless connectivity in a local area (e.g., a business location, a residence, a vehicle, a campus, etc.). In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE802.11. In another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). Figure 1A As shown, the base station 114b can be directly connected to the Internet 110. Thus, the base station 114b can access the Internet 110 without going through the core network 106.

[0028] The RAN 104, and more particularly one or more nodes or components thereof, may be in communication with a core network 106, which may be any type of network configured to provide voice, data, application and / or voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although in Figure 1A Although not shown, it will be appreciated that the RAN 104 and / or the core network 106 may be in direct or indirect communication with other RANs, and that these RANs may employ the same RAT as the RAN 104 or different RATs. For example, in addition to being connected to the RAN 104, which may utilize E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) utilizing GSM radio technology.

[0029] The core network 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer network devices that use a common communication protocol, and the protocol may be the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may use the same RAT as the RAN 104 or a different RAT.

[0030] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, that is, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. Figure 1A The WTRU 102c shown may be configured to communicate with the base station 114a utilizing a cellular-based radio technology, and with the base station 114b utilizing an IEEE 802 radio technology.

[0031] Figure 1B is a system diagram of an example WTRU 102. Figure 1B As shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a numeric keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing components while remaining consistent with the embodiments.

[0032] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, however it should be appreciated that the processor 118 and the transceiver 120 may also be integrated into one electronic component or chip.

[0033] The transmit / receive component 122 may be configured to transmit or receive signals to and from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in another embodiment, the transmit / receive component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In another embodiment, the transmit / receive component 122 may be configured to transmit and receive RF and light signals. It should be appreciated that the transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.

[0034] In addition, although Figure 1B 102 as a single component, but the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) for transmitting and receiving radio signals over the air interface 116.

[0035] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive component 122 and to demodulate signals received by the transmit / receive component 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0036] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a numeric keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from these components. The processor 118 may also output user data to the speaker / microphone 124, the numeric keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store information in any suitable memory (e.g., a non-removable memory 130 and / or a removable memory 132). The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as, for example, on a server or a home computer (not shown).

[0037] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power for other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0038] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable positioning method while remaining consistent with an embodiment.

[0039] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, modules, FM radio units, digital music players, media players, video game console modules, and Internet browsers, among others.

[0040] Figure 1C 1 is a system diagram of the RAN 104 and the core network 106 according to one embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c using an E-UTRA radio technology over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0041] The RAN 104 may include eNode-Bs 140a, 140b, 140c, however it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. Each of the eNode-Bs 140a, 140b, 140c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, for example, the eNode-B 140a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0042] Each eNodeB 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, and uplink and / or downlink user scheduling, among other things. Figure 1C As shown, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0043] Figure 1C The illustrated core network 106 may include a mobility management gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. Although each of the foregoing components are described as being part of the core network 106, it should be appreciated that any of these components may be owned and / or operated by an entity other than the core network operator.

[0044] The MME 142 may be connected to each of the eNode-Bs 140a, 140b, 140c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation / deactivation processing, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that use other radio technologies, such as GSM or WCDMA.

[0045] The serving gateway 144 may be connected to each of the eNode-Bs 140a, 140b, 140c in the RAN 104 via an S1 interface. The serving gateway 144 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions such as anchoring the user plane during inter-eNode-B handovers, triggering paging processing when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0046] The serving gateway 144 may also be connected to a PDN gateway 146, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0047] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. As an example, the core network 106 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, and the IP gateway may serve as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0048] The other networks 112 may further be connected to a wireless local area network (WLAN) 160 based on IEEE 802.11. The WLAN 160 may include an access router 165. The access router may include gateway functionality. The access router 165 may communicate with multiple access points (APs) 170a, 170b. The communication between the access router 165 and the APs 170a, 170b may be performed via wired Ethernet (IEEE 802.3 standard) or any type of wireless communication protocol. The AP 170a wirelessly communicates with the WTRU 102d over an air interface.

[0049] Figure 2 An example architecture for supporting Gateway Tunneling Protocol (GTP) based mobility in LTE Evolved Packet Core (EPC) is shown. The mobility management framework of EPC is designed around the "always-on" principle and is built on top of the network controlled mobility protocol GTP. In one example, data flow 213 travels between WTRU 210 at location a and PDN 202. Figure 2 In the illustrated example architecture, there may also be an MME 203 and an S-GW 205 that facilitate data flows 213. The WTRU 210 is attached to a mobility anchor point (e.g., P-GW 201) which is a centralized network entity and remains attached to the same point as it moves around. The P-GW 201 assigns an IP address 212 to the WTRU 210 and the IP address 212 is used as an identifier and address locator for the WTRU 210. GTP tunnels 206a, 206b, and 204 are established between the mobility anchor point and the WTRU's serving access network (e.g., eNBs 208a and 208b). When the WTRU 210 moves from location a to location b in the network and a serving access network change is triggered (e.g., a mid-session handover between eNBs or a tracking area update including S-GW reallocation), the network will manage / move the GTP tunnel of the WTRU 210 to "follow" the current location of the WTRU, e.g., from GTP 208a at location a to GTP 208b at location b. As long as the incoming data flow 213 travels through the established GTP tunnels 204 and 206b after moving to location b, it will find the destination WTRU 210. The WTRU's IP address 212 will remain the same when moving across access networks, and the WTRU 210 will not be aware of the tunnel management.

[0050] Data routing within the 3rd Generation Partnership Project (3GPP) network follows the following rules: Figure 2The established GTP tunnel is shown. In the 3GPP network, the GTP tunnel of the WTRU is identified by the GTP tunnel ID. For example, for the uplink between eNB 208a and S-GW 205, the GTP tunnel ID "UL S1-TEID" may be assigned to GTP tunnel 206a, and for the uplink between S-GW 205 and P-GW 201, the GTP tunnel ID "UL S5-TEID" may be assigned to GTP tunnel 204. The tunnel ID is carried in the header of each GTP-U data, so that the GW can easily find the next hop of the data route.

[0051] Figure 2 The mobility framework discussed in the example of can be used for and optimized for inter-personal communications, where the WTRU is a smartphone and it is assumed that the smartphone needs to roam at a certain speed. One goal of the system design is to achieve service continuity when the WTRU is moving at high speeds. There is no difference in mobility support for WTRUs with different mobility levels. The common mobility framework applies to all WTRUs, regardless of their mobility level or whether they need service continuity.

[0052] In the discussion on the mobility framework for next generation networks, the need for "mobility on demand" is emphasized. There are at least two use cases for mobility on demand. In the first use case, the WTRUs may include different device types and uses, which may have different mobility levels (for example, some WTRUs may be mobile at high speeds, while other WTRUs may follow a nomadic mode, or may be fixed), and different mobility levels may require different mobility support. In the second use case, different applications and services running on the WTRU may require different mobility support. For example, some applications may handle mobility events at the application layer and do not require traditional network layer mobility support.

[0053] To support "mobility on demand", the following considerations may need to be addressed: how to support mobility on demand and different types of mobility; the types of mobility that the system should support (e.g., high mobility, medium mobility, low mobility, no mobility, and mobility on demand); how to determine the type of WTRU mobility (e.g., through what features / methods); and / or how to obtain information (e.g., application needs, WTRU capabilities, services used) to determine the appropriate type of mobility for the WTRU.

[0054] Examples of different "mobility levels" or mobilities may include any one or a combination of the following: mobility supported over a specified area within a single RAN node; supported mobility levels within a single RAN node (i.e. equivalent to an eNodeB); mobility supported between RAN nodes in a RAN registration area (i.e. equivalent to a TA in an EPC); mobility supported in the service area of ​​a control plane or user plane CN entity (i.e. equivalent to an MME pool area or a serving GW service area in an EPC); mobility supported within a specified RAT or a combination of RATs integrated at the RAN level (e.g. LTE and 5G RAT); or mobility supported between more than one access technologies.

[0055] In general, the mobility framework in the next generation network may need to address different mobility levels and provide appropriate solutions. In particular, the mobility support for low-mobility WTRUs or fixed WTRUs may need to be accommodated in the next generation network.

[0056] In a GTP-based 3GPP network, data routing follows the pre-established GTP tunnel. Each GTP-U header contains the tunnel ID, so the GW can easily find the next hop.

[0057] An alternative approach to GTP-based mobility management may be used for low mobility WTRUs because IP anchoring may not be necessary when the WTRU is stationary or only moving within a very limited area, especially when the WTRU does not require perfect service continuity. In addition, establishing a GTP tunnel may require a large amount of signaling, which may be problematic if there are a large number of low mobility WTRUs. Since GTP is unlikely to be used for mobility changes for low mobility WTRUs and when GTP tunnels are not available, it is necessary to address data routing mechanisms within the 3GPP core network for low mobility WTRUs.

[0058] For IP data routing, alternative routing mechanisms may be used for low mobility WTRUs. One or more low mobility WTRUs may use non-IP data communications. For example, one or more low mobility WTRUs may be low-cost devices without an IP stack. Also, IP packets may have a large header overhead, which is undesirable for a large number of low mobility WTRUs. Thus, the methods and systems discussed herein may be used to support non-IP data routing for low mobility WTRUs.

[0059] In one embodiment, data can be routed based on non-IP addresses within the 3GPP network. In such embodiments, non-IP data will still be routed through the IP network because outside the 3GPP network, the data infrastructure is mostly IP-based. Such embodiments can follow the general principles of next-generation core networks including 5G and new radio technologies, such as complete CP / UP separation, virtualized network functions, network slicing, and routing based on software-defined networks (SDN). Moreover, such implementations will be very efficient and will not generate a lot of overhead.

[0060] In one example, data routing can be solved by parsing it into two parts: non-IP routing inside the 3GPP network and IP routing outside the 3GPP network. The ingress / egress GW located at the boundary of these two parts can convert between non-IP data and IP packets. The ingress / egress GW can assign a temporary device IP address to the WTRU with the help of the GW controller to convert the non-IP data into IP data, and can maintain the mapping between the device ID and the temporary device IP. In the downlink, the ingress / egress GW can use the stored mapping information to look up the device ID of the WTRU, thereby converting the IP packet into non-IP data. In one example, the routing path inside the 3GPP network can be established using SDN-based technology, and a combination of device ID / service ID can be used as a routing tag.

[0061] Figure 3 An example architecture for supporting non-IP data routing for non-IP WTRUs is shown. Figure 3 In FIG. 3 , the entire routing path is divided into two parts: a non-IP routing part 311 and an IP routing part 312. The non-IP routing part 311 is located inside the 3GPP network, between the RAN 304 (i.e., a node or component) or an access gateway and the ingress / egress GW 307. The IP routing part 312 is between the 3GPP ingress / egress GW 307 and the destination (e.g., a service / application server 310 or a peer WTRU (not shown) outside the PDN 309). The WTRUs 301a-d can send non-IP data to the destination (e.g., the service / application server 310) through the non-IP routing domain part 311 and the IP routing domain part 312.

[0062] exist Figure 3 In the present invention, the architecture for non-IP data routing assumes that the infrastructure network external to the 3GPP network is IP-based. However, if the infrastructure network external to the 3GPP network is not IP-based (e.g., it uses a non-IP protocol different from the non-IP protocol inside the 3GPP network), then the systems and methods described herein can be applied.

[0063] exist Figure 3 As can be seen in FIG, each non-IP WTRU 301a-d is assigned an ingress gateway 307 that receives all incoming data from outside the PDN 309 and forwards it to the non-IP WTRU (e.g., 301a) and an egress gateway 307 that terminates all outgoing data from the non-IP WTRU 301a and forwards it to a destination outside the PDN 307. The ingress / egress GWs 307 can be either separate (not shown) or combined in one physical entity.

[0064] The ingress / egress GW 307 of the non-IP WTRU 301a is assigned by the GW controller 306. The GW controller 306 may also select one or more other routing GWs 305 to form a non-IP routing path between the RAN 304 and the ingress / egress GW 307. The GW controller 306 may also configure (possibly by using SDN-based APIs) routing tables in other routing GWs 305 located in the non-IP routing path, thereby ensuring that non-IP data is routable between the RAN 304 and the ingress / egress GW 307. The GW controller 306 may obtain the IP of the destination service / application server 310 located outside the PDN 308 by querying the service DNS 308.

[0065] The non-IP WTRUs 301a and 301b may be connected to the network directly or indirectly through a capillary GW, such as WTRUs 301c and 301d. The non-IP WTRUs 301a-d may register with a local RAN 304 or a mobility control function 303 in the core network. After device registration, the RAN 304 or the mobility control function 303 interacts with the selected GW controller 306 to establish a non-IP routing path.

[0066] Combination Figure 3 One or more of the main functions described may be instances of virtualized network functions, and these functions may be organized into network slices for non-IP services. Furthermore, the control plane functions and user plane functions of the GW may not necessarily be the same. Figure 3 Instead of being shown as separate, they may reside in one GW entity.

[0067] And, in Figure 3 In the example, at the boundary between the non-IP routing part 311 and the IP routing part 312, non-IP data may be converted into IP data by the egress / ingress GW 307, and vice versa, wherein the conversion may be performed under the control of the GW controller 306.

[0068] Figure 4 An example of a Non-IP Data Protocol / Format (NIDP) data format is shown. By defining NIDP, the protocol can be followed to establish a forwarding table in a routing path. The NIDP header 401 may include a service ID 403 or a combination of a device ID 402 and a service ID 403 as a routing tag. In order to implement non-IP data forwarding processing based on the NIDP header 401, each non-IP data from the WTRU should include a device ID and a service ID. Service priority information 404 may also be included in the NIDP header 401. Following the NIDP header 401 may be a NIDP payload 405 containing an application data payload 406. Figure 4 The example NIDP header shown may include security or encryption information as compared to more complex header designs.

[0069] Figure 5 shows a method for supporting non-IP data routing architecture (such as Figure 3 504). The WTRU 501 may have an application 502 that must pass data to an application server 516 through a RAN 505 and an ingress / egress GW 510. SDN-based routing (e.g., Openflow routing) may be used for the non-IP data routing portion within the 3GPP core network. Each gateway may have a separate non-IP data routing or forwarding table. The WTRU 501 may also have a NIDP 503 and a RAN air interface 504. The WTRU 501 communicates with the RAN 505 over the air interface 504. The GW controller may configure each GW in the path from the RAN 505 to the selected egress GW 510 with a forwarding table entry that directs the data to the appropriate next hop. The ingress / egress GW 510 may have the following protocol stack layers: application 513, NIDP 511, UDP 514, layer 2 or layer 3 512, IP 515, and layer 2 520, and may include any technology over which IP can be transported, such as MPLS and ATM, etc. The application server 516 may have the following protocol stack layers: application 517, UDP 518, IP 519, and layer 2 521, and may include any technology over which IP can be transported, such as MPLS and ATM, etc.

[0070] Figure 6 An example method for routing outgoing non-IP data is shown. For this example, it is assumed that the non-IP WTRU has selected a network / network slice and a RAN.

[0071] At 607, the non-IP WTRU 601 registers with the network or network slice. The RAN 602 or a mobility control function (MCF) in the core network may handle such registration. The registration identifies the device ID and its location to the network.

[0072] At 608, upon receiving the registration request from WTRU 601, RAN 602 or MCF may select a GW controller 603 and may request the GW controller 603 to establish a non-IP data routing path for WTRU 601, which may include information such as device ID, service ID, and RAN address.

[0073] At 609, the GW controller 603 selects the egress GW 604 and any other necessary routing GWs. At 610, the GW controller 603 also configures these GWs (including the RAN 602 or access gateways) using a forwarding table based on the device ID; the forwarding table may include a mapping between the device ID and the next hop address, so that the GW can determine the next hop address by looking up the device ID in the table.

[0074] At 611, the WTRU 601 sends non-IP data to the RAN 602, the NIDP datagram header will provide the device ID, where the routing GW will forward the data to the egress GW 604 by using the device ID.

[0075] At 612, the non-IP data arrives at the egress GW 604, and if the egress GW 604 does not have a routing context for the device ID, then at 613, the egress GW 604 initiates a request to the GW controller 603 for a temporary IP address for the WTRU 601. At 614, the GW controller 603 assigns the requested temporary IP address to the WTRU 601. At 615, the GW controller also queries the DNS server 605 using the service ID provided in the NIDP data to obtain the destination IP address.

[0076] At 616, the egress GW 604 receives the IP assignment response from the GW controller 603, wherein the response includes information such as a temporary device IP address and a destination IP, etc. At 617, the egress GW 604 uses the temporary device IP address and the destination IP to convert the NIDP data into an IP routable packet, and then at 618, the egress GW 604 forwards the IP packet to the destination server 606.

[0077] In view of Figure 6One purpose of device registration is for the WTRU to provide the network with its "device ID" and "service ID", which will form the routing tags used in non-IP data routing. Device registration may also identify the location of the WTRU (e.g., in the form of a layer 2 address of the connected RAN or access gateway). The GW controller may use the location information to configure its routing for incoming data.

[0078] The "Device ID" and "Service ID" can take many forms: they can be text strings, URIs, IMEI numbers, or public cryptographic keys (in conjunction with the Host Identity Protocol (HIP)), among others.

[0079] It should be noted that the WTRU may indicate one or more service IDs during the registration process and each service ID may be associated with a priority.

[0080] In addition to the device ID and one or more service IDs, other necessary capability indications may also be signaled to the network during the registration process, such as a "low mobility" indication, a "non-IP data device" indication, a "pure outgoing data" flag, a "pure incoming data" flag, and a "both incoming and outgoing data" flag. The WTRU may also report parameters related to its reachability, such as power save mode or extended DRX settings.

[0081] The RAN or other network entities (eg, mobility control functions) may process the device registration. In addition, other processes also exist, such as device authentication and authorization processes combined with the device registration process.

[0082] Figure 7 An example of selecting different egress GWs for different non-IP data services is shown. Each non-IP WTRU 760 should be assigned an egress GW, such as egress GW 706 or 708. Figure 3 As shown, the egress GW may be located at the boundary between the 3GPP core network and the external PDN. As described herein, the egress GW terminates non-IP data transmissions, converts them into IP routable packets, and forwards the packets to a destination in an IP network.

[0083] The selection of the egress GW (e.g., egress GW 706 or 708) may be performed by the GW controller 701 or other network entities / functions (e.g., mobility control functions). In one embodiment, this task is performed by the GW controller 701, because the GW controller 701 also needs to select other routing GWs between the RAN 703 and the selected egress GW, and needs to configure the routing tables in these GWs. If the egress GW selection is performed by other entities / functions, it is necessary to inform the GW controller 701 of the address of the selected GW.

[0084] The selection of the egress GW may be triggered by device registration or some other process. Once the device is registered, the RAN 703 or MCF (not shown) sends a "routing request" to the GW controller 701, which then selects an egress GW (e.g., egress GW 706 or 708) and other necessary routing GWs between the RAN 703 and the selected egress GW. The selection of the GW may also be delayed until the WTRU 702 sends its first non-IP data.

[0085] The egress GW may be selected based on the service ID received from the routing request. The egress GW may not support all non-IP data services, but only a small portion of them, so the selected egress GW should satisfy the indicated service ID. If multiple service IDs are indicated, the GW controller may select the same or different egress GW for each service ID. Before selecting an egress GW, the GW controller 701 may also need to query the DNS for the IP address of the device ID.

[0086] In one embodiment, when the WTRU 702 sends non-IP data with service ID1 710, the non-IP data is routed by the GW controller through routing GW1 704, routing GW2 705, and reaches the egress GW 706, where it is sent to its final destination by using IP services. In another embodiment, when the WTRU 702 sends non-IP data with service ID1 709, the non-IP data is routed by the GW controller 701 and passes through routing GW1 604, routing GW2 707, and reaches the egress GW 708, where it is sent to its final destination by using IP services.

[0087] In one embodiment, there may be a process for assigning a temporary device IP and performing a destination IP lookup. When the NIDP data arrives at the egress GW, the egress GW may check if it has a context for the device ID and if the IP address is available. If not, then the egress GW may request the GW controller to assign a temporary IP address to the WTRU. The GW controller itself may have a pool of IP addresses for this function. It may also use other entities, such as a DHCP server, for this purpose.

[0088] In addition, the GW controller is also requested to use the DNS service to resolve the destination IP for the service ID. The transmission port number (eg, UDP port) also needs to be obtained.

[0089] Upon receiving a routing request for a WTRU, the GW controller may have performed temporary IP allocation and destination IP resolution and may have saved it with the WTRU's context. The GW controller will return this information to the egress GW when requested.

[0090] Under certain conditions, the GW controller may modify or release the temporary IP of the WTRU. For example, if the ingress or egress GW reports that the WTRU has been inactive for a long time, the GW controller may release the temporary IP assignment and use it for another WTRU. The WTRU may or may not receive a network indication of a change in the temporary IP address, depending on whether the application server can handle such an IP change.

[0091] The egress GW can also perform IP address allocation and destination IP resolution by itself without the aid of the GW controller.

[0092] In another embodiment, the source IP address assignment performed by the GW controller node can be based on the service type or service ID contained in the IP assignment request message. The GW controller node can check the service ID contained in the request message for requesting the source IP, and can in turn check the urgency or priority of the request obtained from the information. The GW controller can then decide the IP address version (IPv4 or IPv6), IP address type (temporary address or permanent IP address), and QoS (DSCP value) associated with the IP address / connection.

[0093] If the decision made by the GW node is to assign a temporary IP address, then it may be necessary to define some other parameters to clarify the scope of the temporary IP address (such as the validity of the temporary IP address). The length of existence of the temporary IP address may be notified to the egress GW. The notification may be measured in time units (such as seconds or minutes), or it may be measured in WTRU connection state, where a specific IP address can be used as long as the WTRU is in the connected state. Whenever the WTRU encounters a state transition between idle and connected mode, it will need to request a new IP address.

[0094] Alternatively, the GW controller may decide to assign permanent IP addresses for certain service IDs or types. Low latency type services (such as health monitoring applications and V2X services) are some examples where a permanent IP address may be assigned by the GW controller. The permanent IP address will remain valid for the lifetime of the device registration. As long as the WTRU is attached or registered to the network, the GW can use the same permanent source IP address for all outgoing packets for that particular WTRU.

[0095] With the assigned temporary device IP address, the resolved destination IP, and the UDP port number, the egress GW can convert the received NIDP data into IP packets using the device IP as the source IP address, and can forward it to the external IP network.

[0096] Figure 8 An example of a method for performing routing processing for incoming non-IP data is shown. If the WTRU 801 has already sent outgoing data to an external IP network (either an application server or a peer WTRU 801), then the incoming data should have the temporary IP address of that WTRU as the destination address. If the WTRU 801 has not previously sent outgoing data, then the server or other peer WTRU cannot send IP packets to the 3GPP network. In the latter case, the server may need to trigger the non-IP WTRU 801 to send outgoing data first (e.g., at 805, where the WTRU 801 sends an application registration message containing a device ID and a service ID to the RAN 802).

[0097] At 806, the RAN 802 may send a routing request to the GW controller 803 using the information received in the application registration message and the RAN address. At 807, the GW controller 803 may assign a temporary device IP and resolve the destination IP. At 808, the mapping information may be sent from the GW controller 803 to the ingress GW 804. In one example, the mapping information may include a concordance of device ID / service ID and device IP / destination IP. At 809, the ingress GW may store the mapping information for use when information is sent to the WTRU 801.

[0098] At 810, incoming data for the non-IP WTRU 801 may enter at the ingress GW 804. The ingress GW 804 may be implicitly selected after performing the temporary IP assignment discussed herein. In one embodiment, the ingress GW is the same GW as the egress GW, but in another embodiment, a separate ingress GW is equally possible. The process for selecting other GWs between the RAN 802 and the ingress GW 804 for incoming data may be performed along with the GW selection process for outgoing data. Likewise, the routing GW for incoming data may be the same or different from the routing GW for outgoing data. In other words, the routing path for incoming data may be the same or different from the path for outgoing data.

[0099] The forwarding table configuration in the GW for incoming data may also be performed together with the configuration for outgoing data. If this is not the case, and the GW in the routing path cannot find a forwarding entry for the received incoming data, the GW may request the GW controller 803 to update the forwarding table.

[0100] And, at 810, when an IP packet carrying a non-IP application data payload arrives at the ingress GW 804, the ingress GW 804 performs a reverse mapping from the IP header information (source IP address, destination IP address) to the device ID and service ID at 811. The mapping information may be created and stored in the ingress GW 804 when the temporary device IP address is assigned at 809. At 812, using the device ID and service ID, the ingress GW 804 may convert the received IP packet into NIDP data format and may forward it to the RAN 802 along the pre-configured routing path. At 813, the RAN 802 completes the process by transmitting the incoming data converted into NIDP data to the non-IP WTRU 801.

[0101] In another embodiment, the IP address assignment service may be exposed to the application server. If the application server has a packet destined for a specific WTRU and does not know the destination IP address, the application server may request the destination IP address through an API message and an exposure function. The exposure function may then contact the GW controller to request the source IP address of the WTRU. Upon receiving this request from the exposure function, the GW function may assign a source IP address to the WTRU. The GW controller may then send this newly assigned source IP address to the exposure function. The API response message may provide the IP address to the application server. When the application server sends a DL IP packet, it may include the received IP address as the destination address in the IP header of the packet. This embodiment assumes that the exposure layer understands the mapping between the external device ID used by the application server in the API request and the device ID and / or service ID. The message of the exposure function for IP address assignment may include an internal device ID and service ID based on the mapping.

[0102] When a non-IP WTRU moves from a RAN to which it was previously connected to a new RAN, data routing needs to be modified so that data reaches the new RAN. Similar to what is described herein, the new RAN may trigger the GW controller to modify outgoing and incoming routes after the WTRU registers with the new RAN. However, one disadvantage of this approach is that the routing path modifications made by the GW controller may introduce significant delays and cause service disruptions.

[0103] Accordingly, in one embodiment, when the WTRU moves to a new RAN, the WTRU may continue to use most of the original routing path established between the previous RAN and the egress / ingress GW, and only the hops between the previous RAN and the first routing GW may be changed to hops between the new RAN and the first routing GW. In this embodiment, the "first routing GW" may be defined as the closest GW in the routing path, or if defined from the perspective of the ingress GW to the RAN, then it is the last routing GW in the path.

[0104] Fig. 9An example method for performing fast routing path modification when a WTRU moves from a previous RAN to a new RAN is shown. 906 shows the previous routing path for non-IP data for WTRU 901 before moving to the new RAN 903. At 907, for outgoing data, the new RAN 903 receives the first routing GW address from the device registration performed by WTRU 901 and uses this address to build its own routing entry mapping at 908 and points it to the first routing GW 904 for WTRU 901. Alternatively, the new RAN 903 retrieves the address of the first routing GW of WTRU 901 from the previous RAN 902. At the first routing GW 904, the source of the previous hop (previous RAN 902 or new RAN 903) is irrelevant because the route is filtered using the device ID and service ID tags, thereby forwarding the data correctly to the destination without any changes.

[0105] At 910, when the first routing GW 904 receives outgoing data from a different RAN address, the first routing GW 904 modifies its downlink routing table to point it to the corresponding new RAN address. This is because the same GW will be used as the "first routing GW" for both outgoing and incoming data, and the other routing GWs in the path are still different for incoming and outgoing data. However, for incoming data, the routing table at the first routing GW 904 will be modified, so that the routing entry for the device ID / service ID will point to the new RAN 903 instead of the previous RAN 902. At 909, due to the modification of the routing entry triggered by the outgoing data, the new RAN 903 may need to send pseudo outgoing data to trigger the modification of the routing entry instead of waiting for the real outgoing data from the WTRU. At 911, the new routing path after the WTRU 901 switches to the new RAN 903 is completed.

[0106] The same routing path modification process may be repeated when the WTRU moves to another RAN, etc. After the new modification, the original routing path may not be the best path, but it should be acceptable considering that the low mobility WTRU may roam in a limited area, roam rarely, or not roam at all.

[0107] Although the features and elements are described above in specific combinations, it will be recognized by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware that is introduced into a computer-readable medium for operation by a computer or processor. Examples of computer-readable media include electrical signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any computer host.

Claims

1. A network node for facilitating communication between a non-IP system and an IP system, comprising: one or more receivers operably coupled to the one or more processors, the one or more receivers configured to receive non-IP data including a header with a service ID from a wireless transmit / receive unit (WTRU); The one or more receivers are configured to receive an IP address for association with the WTRU; as well as one or more transmitters operably coupled to the one or more processors and configured to transmit IP data packets to a destination server outside the non-IP system, wherein said non-IP data is converted into said IP data packets by using said received IP address, wherein the IP data packet contains the service ID; and The destination is determined based on the service ID.

2. The network node of claim 1, wherein the header further comprises a device ID, wherein the device ID is selected from the group consisting of a text string, a universal resource indicator (URI), an IMEI, or a public cryptographic key.

3. The network node of claim 1, wherein the service ID is selected from the group consisting of a text string, a universal resource indicator (URI), an IMEI, or a public cryptographic key.

4. The network node of claim 1, wherein the one or more processors and the one or more receivers are further configured to receive a registration request including the service ID from the WTRU.

5. The network node of claim 4, wherein the one or more processors and the one or more transmitters are further configured to send a configuration information request to a gateway device based on the registration request, and receive configuration information including a forwarding table from the gateway device, The configuration information request includes the device ID, the service ID and the network node address.

6. The network node of claim 1, wherein the header includes a priority field.

7. The network node of claim 4, wherein the registration request further comprises one or more of: a low mobility indication, a non-IP data device indication, a pure outgoing data flag, a pure incoming data flag, or an outgoing and incoming data flag.

8. The network node of claim 1, wherein the destination is further determined based on a WTRU ID.

9. A method implemented by a network node to facilitate communication between a non-IP system and an IP data system, the method comprising: receiving non-IP data including a header with a service ID from a wireless transmit / receive unit (WTRU); receiving an IP address for association with the WTRU; and transmitting IP data packets to a destination outside said non-IP system, wherein said non-IP data is converted into said IP data packets by using said received IP address, wherein the IP data packet contains the service ID; and The destination is determined based on the service ID.

10. The method of claim 9, wherein the header further comprises a device ID, wherein the device ID is selected from the group consisting of a text string, a universal resource indicator (URI), an IMEI, or a public cryptographic key.

11. The method of claim 9, wherein the service ID is selected from the group consisting of a text string, a universal resource indicator (URI), an IMEI, or a public cryptographic key.

12. The method of claim 9, further comprising receiving a registration request including the service ID from the WTRU.

13. The method of claim 12, further comprising: Based on the registration request, sending a configuration information request to the gateway device; as well as receiving configuration information including a forwarding table from the gateway device, The configuration information request includes the device ID, the service ID and the network node address.

14. The method of claim 9, wherein the header includes a priority field.

15. The method of claim 12, wherein the registration request further comprises one or more of: a low mobility indication, a non-IP data device indication, an outgoing data only flag, an incoming data only flag, or an outgoing and incoming data flag.

16. The method of claim 9, wherein the destination is further determined based on a WTRU ID.

Images