Mobility Management in Information-Centric Networking

Abstract

Systems and methods for handover in an information-centric network are described. An ICN‑CF receives an update request from an ICN ICN‑AMF indicating that a UE is to be handed over from a source NG‑RAN to a target NG‑RAN. The ICN‑CF transmits an update request to an ICN router, the update request being used to update a PIT and / or a FIB table to enable data communication with the UE after the handover. The request includes the UE and the target NG‑RAN, and if the source ICN‑PoA and the target ICN‑PoA are different, the request includes the source ICN‑PoA, the target ICN‑PoA, and the ICN‑GW.

Description

[0001] This application claims priority to U.S. Provisional Patent Application Serial No. 62 / 755,262, filed on November 2, 2018, which is incorporated herein by reference in its entirety. Technical Field

[0002] Embodiments relate to radio access networks (RANs). Some embodiments relate to cellular networks, including 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), 4th Generation (4G) and 5th Generation (5G) New Radio (NR) (or Next Generation (NG)) networks. Some embodiments relate to mobility management in Information Centric Networking (ICN) NG networks. Background Art

[0003] The use of various types of systems has increased due to the increase in the number and types of user equipment (UE) using network resources and the increase in both the amount of data and bandwidth used by various applications such as video streaming operating on these UEs. Bandwidth, latency and data rate improvements can release the increasing demand for network resources. The next generation of wireless communication systems will provide ubiquitous connectivity and access to information, as well as the ability for various users and applications to share data. NG systems are expected to have a unified framework in which different and sometimes conflicting performance standards and services are to be met. For example, in an ICN system, the tracking of UE mobility may be different from the methods used in a 4G system. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] In the drawings, which are not necessarily drawn to scale, like numbers may describe similar components in different views. Like numbers with different letter suffixes may represent different instances of similar components. The accompanying drawings generally illustrate various aspects described in this document by way of example and not by way of limitation.

[0005] Figure 1 A combined communication system according to some embodiments is shown.

[0006] Figure 2 A block diagram of a communication device according to some embodiments is shown.

[0007] Figure 3 Information-Centric Networking (ICN) request / response is shown according to some embodiments.

[0008] Figure 4 An ICN 5G architecture according to some embodiments is shown.

[0009] Figure 5 is an inter-NG-RAN ICN handover procedure according to some implementation schemes.

[0010] Figure 6is another inter-NG-RAN ICN handover procedure according to some embodiments.

[0011] Fig. 7A It is the first part of the N2-based NG-RAN inter-handover procedure according to some embodiments.

[0012] Figure 7B According to some embodiments Fig. 7A The second part of the N2-based NG-RAN inter-handover procedure.

[0013] Figure 8 is an ICN switching method according to some embodiments.

[0014] Fig. 9 is an ICN context update method according to some embodiments.

[0015] Fig.10 is an ICN service request method according to some implementation schemes. DETAILED DESCRIPTION

[0016] The following description and accompanying drawings sufficiently illustrate specific aspects to enable those skilled in the art to practice these aspects. Other aspects may incorporate structural changes, logical changes, electrical changes, process changes, and other changes. Portions and features of some aspects may be included in or replace portions and features of other aspects. Aspects set forth in the claims encompass all available equivalents in those claims.

[0017] Figure 1 A combined communication system according to some embodiments is shown. System 100 includes 3GPP LTE / 4G and 5G network functions. The network functions may be implemented as discrete network elements on dedicated hardware, as software instances running on dedicated hardware, or as virtualized functions instantiated on an appropriate platform (e.g., dedicated hardware or cloud infrastructure).

[0018] The Evolved Packet Core (EPC) of the LTE / 4G network contains protocols and reference points defined for each entity. These core network (CN) entities may include a Mobility Management Entity (MME) 122, a Serving Gateway (S-GW) 124, and a Paging Gateway (P-GW) 126.

[0019] In NG networks, the control plane and the user plane are separated, which can allow independent scaling and allocation of resources for each plane. UE 102 can be connected to a radio access network (RAN) 110 and to an NG-RAN 130 (gNB) or an access and mobility function (AMF) 142. RAN 110 can be an eNB or a general non-3GPP access point, such as an access point for Wi-Fi. The NG core network may include multiple network functions in addition to AMF 112. UE 102 can generate, encode, and possibly encrypt uplink transmissions to RAN 110 and / or gNB 130, and decode (and decrypt) downlink transmissions from RAN 110 and / or gNB 130 (where the opposite is true for RAN 110 / gNB130).

[0020] The network functions may include a user plane function (UPF) 146, a session management function (SMF) 144, a policy control function (PCF) 132, an application function (AF) 148, an authentication server function (AUSF) 152, and a user data management (UDM) 128. The various elements are connected by Figure 1 NG reference point connection shown.

[0021] AMF 142 may provide UE-based authentication, authorization, mobility management, etc. AMF 142 may be independent of access technology. SMF 144 may be responsible for session management and IP address allocation for UE 102. SMF 144 may also select and control UPF 146 for data transmission. SMF 144 may be associated with a single session of UE 102 or multiple sessions of UE 102. That is, UE 102 may have multiple 5G sessions. A different SMF may be assigned to each session. Using different SMFs allows each session to be managed separately. Therefore, the functions of each session may be independent of each other. UPF 126 may be connected to a data network, and UE 102 may communicate with the data network, and UE 102 may transmit uplink data to the data network or receive downlink data from the data network.

[0022] AF 148 may provide information about packet flows to PCF 132, which is responsible for policy control to support the desired QoS. PCF 132 may set mobility and session management policies for UE 102. To this end, PCF 132 may use the packet flow information to determine appropriate policies for the correct operation of AMF 142 and SMF 144. AUSF 152 may store data for UE authentication. UDM 128 may similarly store UE subscription data.

[0023] The gNB 130 may be a standalone gNB or a non-standalone gNB, for example, operating in dual connectivity (DC) mode as a booster controlled by the eNB 110 via an X2 or Xn interface. At least some of the functionality of the EPC and NG CN may be shared (or, separate components may be used for each of the combined components shown). The eNB 110 may be connected to the MME 122 of the EPC via an S1 interface, and to the SGW 124 of the EPC 120 via an S1-U interface. The MME 122 may be connected to the HSS 128 via an S6a interface, and the UDM may be connected to the AMF 142 via an N8 interface. The SGW 124 may be connected to the PGW 126 (control plane PGW-C via S5-C, and user plane PGW-U via S5-U) via an S5 interface. The PGW 126 may serve as an IP anchor for data over the Internet.

[0024] Among other things, the NG CN as described above may include AMF 142, SMF 144, and UPF 146. eNB 110 and gNB 130 may communicate data with SGW 124 of EPC 120 and UPF 146 of NG CN. If the N26 interface is supported by EPC 120, MME 122 and AMF 142 may be connected via the N26 interface to provide control information between MME 122 and AMF 142. In some embodiments, when gNB 130 is a standalone gNB, 5G CN and EPC 120 may be connected via the N26 interface.

[0025] Figure 2 A block diagram of a communication device according to some embodiments is shown. In some embodiments, the communication device may be a UE (including IoT devices and NB-IoT devices), an eNB, a gNB, or other equipment used in a 4G / LTE or NG network environment. For example, the communication device 200 may be a dedicated computer, a personal or laptop computer (PC), a tablet computer, a mobile phone, a smart phone, a network router, a switch or a bridge, or any machine capable of (sequentially or otherwise) executing instructions specifying the actions to be taken by the machine. In some embodiments, the communication device 200 may be embedded in other non-communication-based devices such as vehicles and appliances.

[0026] Examples as described herein may include a logical component or multiple components, modules or mechanisms, or may operate on a logical component or multiple components, modules or mechanisms. Modules and components are tangible entities (e.g., hardware) that can perform specified operations and can be configured or arranged in some way. In one example, a circuit may be arranged as a module in a specified manner (e.g., internally or relative to an external entity such as other circuits). In one example, all or part of one or more computer systems (e.g., independent computer systems, client computer systems, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application parts, or applications) to operate to perform a specified operation of the module. In one example, the software may reside on a machine-readable medium. In one example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operation.

[0027] Thus, the term "module" (and "component") should be understood to encompass a tangible entity, i.e., an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transiently) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operations described herein. Considering an example where a module is temporarily configured, each module need not be instantiated at any one time. For example, if a module includes a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as corresponding different modules at different times. The software may configure the hardware processor accordingly, for example, to constitute a particular module at one instance in time and to constitute a different module at a different instance in time.

[0028] The computing device 200 may include a hardware processor 202 (e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof), a main memory 204, and a static memory 206, some or all of which may communicate with each other via an interconnection link (e.g., a bus) 208. The main memory 204 may include any or all of a removable storage device and a non-removable storage device, a volatile memory, or a non-volatile memory. The communication device 200 may also include a display unit 210 (such as a video display), a mixed digital and alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse). In one example, the display unit 210, the input device 212, and the UI navigation device 214 may be a touch screen display. The communication device 200 may additionally include a storage device (e.g., a drive unit) 216, a signal generating device 218 (e.g., a speaker), a network interface device 220, and one or more sensors 221, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The communication device 200 may also include an output controller, such as a serial (e.g., Universal Serial Bus (USB)) connection, a parallel connection, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0029] The storage device 216 may include a non-transitory machine-readable medium 222 (hereinafter referred to as a machine-readable medium) on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodied or utilized by any one or more of the techniques or functions described herein. The instructions 224 may also reside successfully or at least partially within the main memory 204, within the static memory 206, and / or within the hardware processor 202 during execution of the instructions 224 by the communication device 200. Although the machine-readable medium 222 is illustrated as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 224.

[0030] The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions for execution by the communication device 200 and causing the communication device 200 to perform any one or more of the techniques of the present disclosure, or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting examples of machine-readable media may include solid-state memory, as well as optical and magnetic media. Specific examples of machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; random access memory (RAM); and CD-ROM and DVD-ROM disks.

[0031] The instructions 224 may also be transmitted or received over a communication network via the network interface device 220 using a transmission medium 226, the transmission or reception being performed using any of a plurality of transmission protocols (e.g., frame relay, Internet Protocol (IP), transmission control protocol (TCP), user datagram protocol (EIDP), hypertext transfer protocol (HTTP), etc.). Exemplary communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile phone network (e.g., a cellular network), a plain old telephone (POTS) network, and a wireless data network. Communications over the network may include one or more different protocols, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards (referred to as Wi-Fi), the IEEE 802.16 family of standards (referred to as WiMax), the IEEE 802.15.4 family of standards, the Long Term Evolution (LTE) family of standards, the Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, NG / NR standards, and the like. In one example, the network interface device 220 may include one or more physical jacks (eg, Ethernet, coaxial, or telephone jacks) or one or more antennas to connect to the transmission medium 226 .

[0032] The communication device 200 may be an IoT device (also referred to as a "machine type communication device" or "MTC device"), a narrowband IoT (NB-IoT) device, or a non-IoT device (e.g., a smartphone, a vehicle UE), any of which may be connected via Figure 1The eNB or gNB shown communicates with the core network. The communication device 200 may be an autonomous or semi-autonomous device that communicates with other communication devices and a wider network (e.g., the Internet) to perform functions such as sensing or control. If the communication device 200 is an IoT device, in some embodiments, the communication device 200 may be limited by memory, size, or functionality, allowing a larger number of devices to be deployed at a similar cost to a smaller number of larger devices. In some embodiments, the communication device 200 may be a virtual device, such as an application on a smartphone or other computing device.

[0033] Current networking architectures are based on IP to transport IP, Ethernet, and non-IP packets. That is, communications are host-to-host, and content delivery relies on a session between two endpoints (a protocol data unit (PDU) session within a cellular network, and typically a TCP session between a client and a server). The maintenance of these end-to-end sessions can be complex and error-prone. In addition, bottlenecks can form anywhere in the network because multiple users may be requesting the same content without the network being aware of the multiple requests, resulting in suboptimal utilization of link resources. Furthermore, within the network (core network and / or data network), the content may not be shared between different users requesting the same content.

[0034] To address this problem, Information Centric Networking (ICN) can be used. Figure 3 Information-centric networking (ICN) request / response according to some embodiments is shown. As shown, ICN works according to a pull-based model, in which two types of packets are defined: interest packets and data packets. Interest packets (requests) can flow from consumers (e.g., laptops or smart phones) through access points and content routers to producers of content (e.g., servers) or to network devices with cached copies of content. The content is retrieved from the producer, and the data packets (responses) traverse the path in the opposite direction. ICN is based on a data structure including a pending interest table (PIT), a forwarding information base (FIB) table, and a content storage (CS). ICN can also use an interest forwarding strategy that obtains input from both the FIB table and network / device measurements to make interest forwarding decisions.

[0035] More specifically, a requester (consumer / client) may send an interest packet with an indicator (e.g., prefix) to identify the desired content (e.g., by the name of the content). The ICN packet may be constructed in a type-length-value (TLV) format. The prefix value may typically be a "name" for identifying the content, but another type of indicator may also be used. The type field of the outer TLV may indicate whether the ICN packet is an interest packet or a data packet. Uniform Resource Identifiers (URIs) are widely used for naming resources, which are constructed based on naming conventions; however, indicators may use identifiers other than URIs. Each forwarding node may check the prefix of the interest packet and check the CS to see if the requested content is already cached in the forwarding node. If so, the forwarding node may reply with a data packet matching the prefix. If there is no match, the interest packet is passed to the PIT to find a matching name; if no match is found, the node records the interest in its PIT and forwards the interest to the next hop or multiple hops (the next hop or multiple hops may also have a cached copy of the requested data or may be closer to the producer) toward the requested content based on the information in its FIB table. The interest packet can also reach the source (producer, which can be a server) and obtain the data packet from the source. As described above, the data packet, no matter where it is retrieved, traverses the path to the consumer in the opposite direction of the interest packet.

[0036] Obviously, ICN can be a session-less protocol, where the consumer (client) requests content (e.g., data blocks) from the network, and the data is retrieved from wherever the content is in the network. Therefore, ICN brings application layer optimization down to the networking layer. That is, functions previously implemented in the application layer, such as edge computing (caching), are naturally supported by ICN in the network layer (L3).

[0037] Mobility management in IP networks has always been an active area, as mobility was not considered in the design of IP. Therefore, in order to transparently transmit / route IP packets to mobile devices, multiple enhancements to IP have been standardized. Mobile ICN mobility can be viewed from three different perspectives: i) subscriber / consumer mobility; ii) publisher / producer mobility; and iii) subscriber and publisher mobility. Named Data Networking (NDN) and Content-Centric Networking (CCN) are specific implementations of ICN, and indicate that subscriber / consumer mobility can be naturally supported in their architectures, because any interest packets that are not satisfied (data packets received in response) due to consumer mobility can be retransmitted from the new location of the consumer. In NDN and CCN, publisher mobility can be more difficult to handle than subscriber / consumer mobility, and instead some methods such as Kite for NDN, Map-Me for CCN, and ID / locator partitioning for NDN / CCN are used. Kite can use a rendezvous server (RV) to create a hop-by-hop path between the RV and the mobile producer by exchanging interest-data packets. Map-Me can create a new type of packet called an Interest Update (IU) that a mobile producer can send from its new location to itself at its previous location. This IU can be used to update the routing tables of nodes between the new location and the old location. And the ID / locator partitioning can rely on partitioning the ICN namespace to support the use of persistent names. This can be achieved through a Mobility Services (MS) agent in each ICN router at the edge of the network (wireless side), each of which can be controlled by an MS controller.

[0038] In ICN, consumer mobility can be handled by retransmitting interest packets that have not yet been satisfied. However, this mechanism may introduce packet loss and delay. On the other hand, producer mobility can use some type of additional "signaling" (e.g., interest updates) to track mobile producers. Currently, continuity of service in ICN may not be of utmost importance because most traffic is not time-sensitive traffic (such as video streaming).

[0039] However, this may change as cellular networks meet stringent requirements for the services they provide (time sensitive applications and non-time sensitive applications) and the architecture is designed to enable seamless mobility (using control plane and Xn interface). That is, the gNB can keep track of active users and appropriately hand over the UE to other gNBs based on various measurements. In other words, the network can always know the location of the UE. Unfortunately, ICN may not be able to support this effectively because the mobility is not tracked by any point of attachment (PoA).

[0040] Therefore, this document presents procedures for handling mobility management. The handover procedures are used for both inter-NG-RAN handover without N2 interface involvement and inter-NG-RAN handover based on N2 interface.

[0041] Figure 4 An ICN 5G architecture according to some embodiments is shown. Figure 4 The architecture shown can support ICN in next generation cellular networks. The ICN Point of Attachment (ICN-PoA) and the ICN Gateway (ICN-GW) are two entities that i) report ICN event information to the ICN Control Function (ICN-CF) to generate charging records for the ICN, and ii) receive information from the ICN-CF about rules and policies to be applied to ICN traffic.

[0042] ICN-PoA may act as the first ICN-aware user plane entity for UEs running ICN applications / services. ICN-GW may be a user plane ICN entity that interfaces with the DN. It should be noted that the ICN-GW and UPF PSA (PDU Session Anchor) may be located in the same entity. Specifically, the ICN-UPF entity may be instantiated, where the functionality of the ICN-GW may be part of the UPF (PSA). The ICN-CF may process ICN-related information and policies, and generate an ICN transaction history between other ICN-related functions. Since various ICN entities may be functional entities, they may be part of existing CN entities to ensure flexible implementation of ICN.

[0043] From the perspective of exchanging ICN-related information in the network, Figure 4 The new functional entities (ICN-CF, ICN-PoA, ICN-GW) shown can enable ICN in NG cellular networks. ICN-PoA can act as the first ICN-aware user plane entity for UEs running ICN applications, and ICN-GW can be a user plane ICN entity that interfaces with DN, which can also support ICN-based solutions. In some embodiments, ICN-GW and UPF PDU Session Anchor (PSA) can be located in the same entity. That is, the ICN-UPF entity can be instantiated, where the function of ICN-GW can be part of (or combined with) UPF (PSA). ICN-CF can process information and policies related to ICN and generate ICN transaction history between other ICN-related functions. These entities can be functional entities and can be combined into existing 5GC entities for flexibility. As used herein, transmission between various entities may include encoding at the sending entity and decoding at the receiving entity.

[0044] Figure 5is an inter-NG-RAN ICN handover procedure according to some embodiments. It will be apparent that Figure 5 This is merely an example and other embodiments may modify or omit Figure 5 Some of the operations shown include Figure 5 Additional operations may be performed that are not shown, and / or operations may be performed in a different order as appropriate. Figure 5 The process shown may be used to handover a UE 502 from a source NG-RAN 504 to a target NG-RAN 506 when both the source NG-RAN 504 and the target NG-RAN 506 are connected to the same ICN-PoA 512 using an Xn interface. As shown, before participating in the handover, the UE 502, the source NG-RAN 504, and the target NG-RAN 506 may participate in handover preparation. This may include the UE 502 measuring reference signals from the source NG-RAN 504 and the target NG-RAN 506, and sending measurements or RRC messaging requiring handover to the source NG-RAN 504, etc. The source NG-RAN 504 may then communicate with the target NG-RAN 506 to prepare for the handover of the UE 502, and the target NG-RAN 506 may or may not accept the handover. After acceptance but before completing the handover procedure, the source NG-RAN 504 may transmit interest packets from the UE 502 to the target NG-RAN 506, and the target NG-RAN 506 may transmit data packets for the UE 502 to the source NG-RAN 504.

[0045] Then, at operation 1, the target NG-RAN 506 may transmit an ICN context information update request to the AMF 508. The ICN context information update request may indicate a handover to the AMF 508. The context information update may include an identity (ID) of the UE, an identity of the source cell, and an identity of the target cell.

[0046] At operation 2, the AMF 508 may pass information about the handover to the ICN-CF 510. The ICN information update request may include the UE ID so that the ICN-CF 510 identifies the name / prefix used by the UE 502 to request data and / or provide content. In addition, since the ICN-CF 510 knows the ICN-PoA 512 to which the UE 502 is connected through the source NG-RAN 504, the ICN-CF 510 may know whether to make a change in the ICN-PoA, or if not, whether to perform a PIT and / or FIB table update in the current ICN-PoA 512.

[0047] If a PIT and / or FIB table update is to be performed, the ICN-CF 510 may indicate this to the current ICN-PoA 512 using a PIT update (incoming aspect) and / or a FIB table update (outgoing aspect) at operation 3. Based on the ID of the UE, the ICN-CF 510 may indicate to the ICN-PoA 512 the name to be updated in the PIT and / or the name to be updated in the FIB table.

[0048] As described above, in an ICN, data packets may follow the reverse path of the interest data packets to reach the consumer (UE 502). In some embodiments, when UE 502 is a consumer and since ICN-PoA 512 is the first ICN-aware element from the UE's perspective, only the incoming aspects of the PIT of ICN-PoA 512 (from source NG-RAN 504 to target NG-RAN 506) may be updated / changed for interest packets sent by UE 502. When UE 502 is a producer, only the outgoing aspects of the FIB table of ICN-PoA 512 (through target NG-RAN 506) may be updated / changed for data packets to be forwarded to the UE's new location.

[0049] After updating / changing the PIT and FIB tables, the ICN-PoA 512 may confirm the successful execution of the PIT and / or FIB table update to the ICN-CF 510 at operation 4. In response, at operation 5, the ICN-CF 510 may send an ICN information update response to the AMF 508. The ICN information update response may confirm the update of the PIT and / or FIB table at the ICN-PoA 512.

[0050] At operation 6, the AMF 508 may send an ICN context information update response to the target NG-RAN 506. The ICN context information update response may confirm that the ICN-PoA 512 has been properly reconfigured (ie, the PIT and / or FIB table has been updated).

[0051] At operation 7, the target NG-RAN 506 may then send a release resources message to the source NG-RAN 504. The release resources message may confirm the successful handover to the source NG-RAN 504 and may trigger the release of resources in the source NG-RAN 504.

[0052] At operation 8, UE 502 may initiate a mobility registration update in different situations. A mobility registration update may be initiated when changing to a new tracking area (TA) outside the UE's registration area while in both CM-CONNECTED and CM-IDLE states. In addition, a mobility registration update may be initiated when UE 502 is to update its capabilities or protocol parameters negotiated during the registration process with or without changing to a new TA.

[0053] Figure 6 is another inter-NG-RAN ICN handover procedure according to some embodiments. It will be apparent that Figure 6 This is merely an example and other embodiments may modify or omit Figure 6 Some of the operations shown include Figure 6 Additional operations not shown in the figure, and / or operations may be performed in a different order as appropriate. Specifically, Figure 6 An inter-NG-RAN handover implementation is shown that reallocates the ICN-PoA; that is, when the source RAN 604 and the target NG-RAN 606 are connected to different ICN-PoAs using the Xn interface.

[0054] Similar to Figure 5 ,exist Figure 6 In the example of FIG. 6 , before participating in the handover, the UE 602, the source NG-RAN 604, and the target NG-RAN 606 may participate in handover preparation. After acceptance but before completing the handover process, the source NG-RAN 604 may transmit interest packets from the UE 602 to the target NG-RAN 606, and the target NG-RAN 606 may transmit data packets for the UE 602 to the source NG-RAN 604.

[0055] At operation 1, an ICN context information update request may be sent by the target NG-RAN 606 to the AMF 608. The ICN context information update request may indicate a handover to the AMF 608. The AMF 608 may provide the information to the ICN router 612 via the ICN-CF 610. The ICN router 612 may include one or more ICN-PoAs. The context information update may include the UE ID, the source cell ID, and the target cell ID.

[0056] At operation 2, AMF 608 may pass information about the handover to ICN-CF 610. The ICN information update request may include a UE ID so that ICN-CF 610 identifies the name / prefix used by UE 602 to request data and / or provide content. The request may also include a source cell ID and a target cell ID. ICN-CF 610 may use the source cell ID and the target cell ID to confirm that the source cell and the target cell are not connected to the same ICN-PoA. ICN-CF 610 may use the UE's ID to know the name / prefix used to request / provide content.

[0057] Operations 3 and 4 illustrate handover communications between the ICN-CF 610 and the ICN router 612 (including the ICN-PoA and ICN-GW). 4 (ICN-CF to ICN router) interface. Since the ICN-PoA changes, at operation 3, the ICN-CF 610 may signal all ICN routers 612 in the core network to update their routing tables, indicating the target ICN-PoA that can be used as a waypoint to reach the name / prefix. That is, the triggered routing update message may include information about the aspects (in the PIT and FIB tables) and the name / prefix to be updated in the routing table of the ICN router 612. The ICN router 612 may include a source ICN-PoA, a target ICN-PoA, and an ICN-GW. If the source ICN-PoA serves the name / prefix of more than one UE, the routing table may be updated accordingly so that the switching UE 602 and other UEs can still reach the content. At operation 4, all ICN routers 612 (including the ICN-PoA) may confirm the routing table update.

[0058] At operation 5, the ICN-CF 610 may send an ICN information update response to the AMF 608. The ICN information update response may confirm that the routing table of each ICN router 612 has been updated.

[0059] At operation 6, the AMF 608 may send an ICN context information update response to the target NG-RAN 606. The ICN context information update response may confirm that the ICN router 612 has been properly reconfigured (ie, the routing table has been updated).

[0060] Then, at operation 7, the target NG-RAN 606 may send a release resources message to the source NG-RAN 604. The release resources message may confirm that the handover is successful and trigger the release of resources in the source NG-RAN 604.

[0061] At operation 8, UE 502 may initiate a mobility registration update in different situations. A mobility registration update may be initiated when changing to a new tracking area (TA) outside the UE's registration area while in both CM-CONNECTED and CM-IDLE states. In addition, a mobility registration update may be initiated when UE 502 is to update its capabilities or protocol parameters negotiated during the registration process with or without changing to a new TA.

[0062] Fig. 7A and Figure 7B FIG. 1 shows an N2-based inter-NG-RAN handover procedure according to some embodiments. It will be apparent that Fig. 7A and Figure 7B This is merely an example and other embodiments may modify or omit Fig. 7A and Figure 7B Some of the operations shown include Fig. 7A and Figure 7B Additional operations not shown in the figure, and / or operations may be performed in a different order as appropriate. Specifically, Fig. 7A and 7B The handover of UE 702 is shown when there is no X2 connection between the source NG-RAN 704 and the target NG-RAN 706. In this case, the source AMF 708 and the target AMF 710 are used to relay the handover information between the source NG-RAN 704 and the target NG-RAN 706.

[0063] Specifically, UE 702 may communicate data via S-NG-RAN 704 and ICN router 714 (which may include ICN-PoA and ICN-GW). Figure 5 and Figure 6 As shown starting with handover preparation between the source NG-RAN and the target NG-RAN, since the source NG-RAN 704 and the target NG-RAN 706 may not be able to communicate directly, the source NG-RAN 704 may determine based on the measurements sent by the UE 702 that handover of the UE 702 will occur. After the source NG-RAN 704 determines that handover of the UE 702 will occur, at operation 1, the S-NG-RAN 704 may send a "handover required" message to the source AMF 708. The "handover required" message may include information about the target NG-RAN 706, and information about the data radio bearers (DRBs) from the source NG-RAN 704 to be used by the target NG-RAN 706.

[0064] In response to receiving the "handover required" message, when the S-AMF 708 cannot further serve the UE 702, at operation 2, the S-AMF 708 may select the T-AMF 710 to serve the UE 702. The selection may be based on the information carried in the "handover required" message.

[0065] After selecting T-AMF 710, S-AMF 708 may initiate a handover resource allocation process. Specifically, at operation 3, S-AMF 708 may send a Namf_Communication_CreateUEContext request for ICN service operation to T-AMF 710 to initiate a handover resource allocation process.

[0066] In response to receiving the Namf_Communication_CreateUEContext request, at operation 4, the T-AMF 710 may transmit a handover request to the T-NG-RAN 706. The handover request may include an identification of the source NG-RAN 704 and other control information supporting the ICN service.

[0067] Upon receiving the handover request from T-AMF 710, at operation 5, T-NG-RAN 706 may send a handover request confirm message to T-AMF 710. The handover request confirm message may include a UE container having an access layer part and a NAS part. The UE container may be transparently sent to UE 702 via T-AMF 710, S-AMF 708, and S-NG-RAN 704. The UE container may also include information about DRBs that can be supported and served.

[0068] After sending the handover request confirm message, at operation 6, T-AMF 710 may send a Namf_Communication_CreateUEContext response to S-AMF 708. The Namf_Communication_CreateUEContext response may include all N2 information for S-AMF 708 to send a handover command to S-NG-RAN 704.

[0069] After receiving the Namf_Communication_CreateUEContext response, at operation 7, the S-AMF 708 may send a handover command to the S-NG-RAN 704. In response to receiving the handover command from the S-AMF 708, at operation 8, the S-NG-RAN 704 may send a handover command to the UE 702. The handover command received by the UE 702 may include a UE container having information about the T-NG-RAN 706.

[0070] After sending the handover command to the UE 702, the S-NG-RAN 704 may forward the DL data received from the ICN router 714 for the UE 702 to the T-NG-RAN 706. The UE 702 may then attempt to synchronize with the T-NG-RAN 706.

[0071] After UE 702 is successfully synchronized with T-NG-RAN 706, at operation 9, UE 702 may send a handover confirmation message to S-NG-RAN 704. After receiving the handover confirmation message, S-NG-RAN 704 may start sending buffered DL data for UE 702 to UE 702.

[0072] In response to receiving the handover confirmation message, at operation 10, the T-NG-RAN 706 may then send a handover notification message to the T-AMF 710. The handover notification message may notify the T-AMF 710 that the UE 702 is successfully handed over to the T-NG-RAN 706.

[0073] After receiving the handover notification message, at operation 11, T-AMF 710 may deliver information about the handover to ICN-CF 712 in an ICN-PoA allocation request. The information provided to ICN-CF 712 may include the UE ID and the target NG-RAN ID involved in the handover.

[0074] Using the UE's ID, the ICN-CF 712 may check in its internal registers for the name / prefix associated with the UE 702 to be updated in the ICN router 714. Using the target cell ID, the ICN-CF 712 may determine the ICN-PoA assigned to the target NG-RAN 706. The ICN-CF 712 may be able to appropriately construct a route update trigger message, which is sent to the ICN router 714 at operation 12. The route update trigger message may include aspects of the modification / update of the PIT and / or FIB table for the ICN router 714 (including the UE, S-NG-RAN, T-NG-RAN, and GW ID). Therefore, the ICN-CF 712 may trigger all ICN routers 714 in the core network to update their routing tables, which update indicates the new ICN-PoA as a waypoint for the UE 702 to reach the prefix at its new location.

[0075] In response to receiving the routing update trigger message, the ICN router 714 (including the ICN-PoA) may confirm the routing table update via a routing table update confirmation message. At operation 13, a routing table update confirmation message may be sent from the ICN router 714 to the ICN-CF 712.

[0076] After receiving the routing table update confirmation message, at operation 14, ICN-CF 712 may send an ICN information update response (ICN-PoA allocation response) to T-AMF 710. The ICN information update response may confirm to T-AMF 710 that the routing tables of all ICN routers have been successfully updated.

[0077] After receiving the ICN information update response, at operation 15a, T-AMF 710 may notify S-AMF 708 of the N2 handover notification message received from T-NG-RAN 706. In order to provide this information, T-AMF 710 may send a Namf_Communication_N2InfoNotify message to S-AMF 708. A timer in S-AMF 708 may be started to supervise when resources in S-NG-RAN 704 are released. S-AMF 708 may also confirm the receipt of the Namf_Communication_N2InfoNotify message by sending a Namf_Communication_N2InfoNotify ACK to T-AMF 710 at operation 15b.

[0078] After operation 14, regardless of whether operations 15a and 15b have occurred, at operation 16, the UE 702 may initiate a mobility registration update using a subset of the registration procedure. After the timer started at operation 15b expires, at operation 17a, the S-AMF 708 may transmit a UE context release command to the S-NG-RAN 704. In response to receiving the UE context release command, at operation 17b, the source NG-RAN 704 may release its resources associated with the UE 702. The source NG-RAN 704 may then respond to the UE context release command with a UE context release complete message sent to the S-AMF 708.

[0079] Figure 8 is an ICN switching method according to some embodiments. Figure 8 The illustrated method may include receiving, at the target gNB, an ICN packet associated with the UE from the source gNB as part of a handover of the UE from the source gNB to the target gNB, at operation 802. In response, at operation 804, the target gNB or the AMF (having received an indication from the target gNB) may send a request to the ICN-CF to update ICN context information about the UE to reflect the handover.

[0080] Fig. 9 is an ICN context update method according to some embodiments. Fig. 9The illustrated method may include receiving a request at an ICN-CF to update ICN context information about a UE to reflect a handover from a source NG-RAN to a target NG-RAN, at operation 902. In response, at operation 904, the ICN-CF may send a message to one or more ICN routers to update a PIT, a FIB table, and / or a routing table based on the handover.

[0081] Fig.10 is an ICN service request method according to some implementation schemes. Fig.10 The method shown may include: at operation 1002, the ICN-CF receives a request for allocating a new ICN-PoA to the UE for ICN services based on a handover from a source NG-RAN to a target NG-RAN. In response, at operation 1004, the ICN-CF may send a message to a plurality of ICN routers to update a routing table based on the handover. At operation 1004, the ICN-CF may also send an allocation message to allocate the new ICN-PoA to the UE.

[0082] For at least some of the above procedures, a routing protocol may be used for the ICN-CF to trigger routing updates. An example of such a protocol is the Named Data Link State Routing protocol (NLSR).

[0083] Although an aspect has been described with reference to specific exemplary aspects, it is apparent that various modifications and changes may be made to these aspects without departing from the broader scope of the present disclosure. Accordingly, the specification and the drawings should be regarded as having illustrative rather than restrictive meanings. The drawings forming part of this document illustrate specific aspects of the practicable subject matter in an illustrative rather than restrictive manner. The aspects shown are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other aspects may be utilized and derived from the present disclosure, so that structural substitutions and logical substitutions and changes may be made without departing from the scope of the present disclosure. Therefore, this specific embodiment is not restrictive, and the scope of each aspect is limited only by the appended claims and the full scope of equivalents to which such claims are authorized.

[0084] An abstract of the specification of the present disclosure is provided to comply with 37 CFR §1.72(b), which requires the provision of an abstract of the specification that will allow the reader to quickly determine the essence of the technical disclosure. The provision of this abstract is based on the understanding that the technical disclosure will not be used to interpret or limit the scope or meaning of the claims. In addition, in the above-mentioned detailed description, it can be seen that various features are concentrated in a single aspect for the purpose of simplifying the present disclosure. The disclosed method should not be interpreted as reflecting the intention that the claimed aspects require more features than the features explicitly recited in each claim. On the contrary, as reflected in the following claims, the subject matter of the invention lies in less than all the features of a single disclosed aspect. Therefore, the following claims are hereby incorporated into the detailed description, wherein each claim exists independently as a separate aspect.

Claims

1. An apparatus for an information-centric networking ICN control function ICN-CF, comprising: Memory; a processing circuit in communication with the memory, wherein the processing circuit is configured to: decoding an ICN context information update request from an ICN access and mobility function ICN-AMF, the ICN context information update request indicating a handover of a user equipment UE from a source radio access node RAN to a target RAN; Determine, based on the source RAN, an ICN point of attachment ICN-PoA to which the UE is connected; In response to determining, based on the target RAN, that another ICN-PoA is to be selected for the UE after the handover, encoding an update indication for transmission to an ICN router, the update indication being used to update the ICN router to indicate that data communications with the UE are to occur through the target RAN, wherein the update indication comprises a triggered routing update message for updating a routing table of the ICN router; responsive to the transmission of the update indication, decoding from the ICN router an acknowledgement that the ICN router has been updated; as well as In response to receiving the confirmation, an ICN context information update response indicating that the ICN router has been reconfigured is encoded for transmission to the ICN-AMF.

2. The apparatus according to claim 1, wherein the processing circuit is further configured to determine the UE according to a UE identity ID in the ICN context information update request, and determine the target RAN according to a target RAN ID in the ICN context information update request.

3. The apparatus of claim 1 , wherein the processing circuit is further configured to: Determine, based on the source RAN, an ICN point of attachment ICN-PoA to which the UE is connected; and A determination is made based on the target RAN whether to select another ICN-PoA for the UE after the handover.

4. The device according to claim 3, wherein: The ICN router is the ICN-PoA; and wherein The processing circuit is further configured to: In response to determining that the ICN-PoA is to be used if the UE is connected to the target RAN, determining that an update of at least one of a pending interest table (PIT) or a forwarding information base (FIB) table is to be performed in the ICN-PoA; as well as At least one of a PIT update indication or a FIB table update indication is encoded as the update indication for the ICN-PoA, the at least one of the PIT update indication or the FIB table update indication including a name of the ICN-PoA to be updated in the at least one of the PIT or the FIB table.

5. The apparatus of claim 4, wherein the processing circuit is further configured to determine the update of the at least one of the PIT or FIB table: If the UE is a consumer, only the incoming aspect of the PIT for interest packets sent by the UE; and If the UE is a producer, it is only the outgoing aspect of the FIB table for data packets to be forwarded to the UE.

6. The apparatus according to claim 1, wherein the triggered route update message indicates the UE and a source ICN-PoA, a target ICN-PoA, and an ICN gateway (ICN-GW) that is a waypoint capable of reaching the UE.

7. The apparatus of claim 6, wherein the processing circuit is further configured to encode the triggering routing update message to a plurality of ICN routers and decode a routing update acknowledgment from each of the ICN routers whose routing tables have been updated.

8. The apparatus of claim 1, wherein the processing circuit is further configured to: determining that the ICN context information update request has been received from a target ICN-AMF, the target ICN-AMF being different from a source ICN-AMF associated with the UE stored in the memory; In response to determining that the ICN context information update request has been received from the target ICN-AMF, determining routing information to be updated in each of a plurality of ICN routers in the 5G network to communicate with the UE; as well as A triggered routing update message including the routing information is encoded for transmission to each of the plurality of ICN routers.

9. The device according to claim 8, in, The processing circuit is further configured to determine a target ICN point of attachment ICN-PoA to which the UE is to be attached based on the target RAN; and The routing information includes an update to at least one of a pending interest table PIT or a forwarding information base FIB table, and the update includes the target ICN-PoA that the ICN router will update in the at least one of the PIT or the FIB table.

10. The apparatus of claim 9, wherein the processing circuit is further configured to: decoding a routing update acknowledgment from each of the ICN routers whose routing tables have been updated; Determining whether the routing table in each of the ICN routers in the 5G network has been updated; as well as In response to determining that the routing table in each of the ICN routers in the 5G network has been updated, a confirmation encoding that the routing table in each of the ICN routers in the 5G network has been updated to communicate with the UE is transmitted to the target AMF.

11. An apparatus for an information-centric networking (ICN) router, comprising: Memory; a processing circuit in communication with the memory, wherein the processing circuit is configured to: decoding a triggered routing update message from an ICN control function ICN-CF, the triggered routing update message instructing a user equipment UE to switch from a source radio access node RAN to a target RAN; In response to receiving the triggered route update message, updating at least one of aspects of a pending interest table PIT or aspects of a forwarding information base FIB table to enable data communication with the UE after the handover, wherein only incoming aspects of the PIT for interest packets sent by the UE are updated when the UE is a consumer, and only outgoing aspects of the FIB table for data packets to be forwarded to the UE are updated when the UE is a producer; and In response to the updating of the at least one of the PIT or FIB table, encoding for transmission to the ICN-CF a confirmation that the at least one of the PIT or FIB table has been updated. 12 . The apparatus according to claim 11 , wherein the triggering route update message comprises a UE identity ID of the UE and a target RAN ID of the target RAN.

13. The apparatus according to claim 12, wherein the triggering route update message further comprises identifiers of a source ICN point of attachment (ICN-PoA) to which the UE is connected before the handover and a target ICN-PoA to which the UE is to be connected after the handover.

14. The apparatus of claim 13, wherein the processing circuit is configured to: determining whether the source ICN-PoA serves at least one UE other than the UE; and If the source ICN-PoA serves the at least one UE, the at least one of the PIT or the FIB table is updated to enable data communication with the UE and the at least one UE other than the UE.

15. The apparatus according to claim 13, wherein the triggering route update message further includes an identification of an ICN gateway (ICN-GW) that is a waypoint capable of reaching the UE.

16. The apparatus of claim 11, wherein the handover is an N2-based handover because there is no Xn interface between the source RAN and the target RAN.

17. A non-transitory computer-readable storage medium storing instructions for execution by one or more processors of an information-centric networking control function (ICN-CF) in a 5th generation (5G) network, wherein when the instructions are executed, the one or more processors configure the ICN-CF to: receiving an ICN context information update request from an ICN access and mobility function ICN-AMF, the ICN context information update request indicating a handover of a user equipment UE from a source radio access node RAN to a target RAN; Transmitting an update indication to an ICN router, the update indication being used to update at least one of a pending interest table PIT or a forwarding information base FIB table in the ICN router to enable data communication with the UE, wherein only an incoming aspect of the PIT for an interest packet sent by the UE is updated when the UE is a consumer, and only an outgoing aspect of the FIB table for a data packet to be forwarded to the UE is updated when the UE is a producer; receiving, in response to the transmission of the update indication, a confirmation from the ICN router that the at least one of the PIT or FIB table of the ICN router has been updated; as well as In response to receiving the confirmation, an ICN context information update response is transmitted to the ICN-AMF indicating that the ICN router has been reconfigured.

18. The non-transitory computer readable storage medium of claim 17, in, The triggering route update message includes the UE identity ID of the UE and the target RAN ID of the target RAN, and If the source ICN point of attachment ICN-PoA is used before the switching and the target ICN-PoA is used after the switching, the triggered route update message further includes a source ICN-PoA ID of the source ICN-PoA and a target ICN-PoA ID of the target ICN-PoA.

19. A method for communication, comprising: Through the information-centric networking control function ICN-CF: decoding an ICN context information update request from an ICN access and mobility function ICN-AMF, the ICN context information update request indicating a handover of a user equipment UE from a source radio access node RAN to a target RAN; Determine, based on the source RAN, an ICN point of attachment ICN-PoA to which the UE is connected; In response to determining, based on the target RAN, that another ICN-PoA is to be selected for the UE after the handover, encoding an update indication for transmission to an ICN router, the update indication being used to update the ICN router to indicate that data communications with the UE are to occur through the target RAN, wherein the update indication comprises a triggered routing update message for updating a routing table of the ICN router; responsive to the transmission of the update indication, decoding from the ICN router an acknowledgement that the ICN router has been updated; as well as In response to receiving the confirmation, an ICN context information update response indicating that the ICN router has been reconfigured is encoded for transmission to the ICN-AMF.

20. The method according to claim 19, further comprising determining the UE according to a UE identity ID in the ICN context information update request, and determining the target RAN according to a target RAN ID in the ICN context information update request.

21. The method of claim 19, further comprising: Determine, based on the source RAN, an ICN point of attachment ICN-PoA to which the UE is connected; as well as A determination is made based on the target RAN whether to select another ICN-PoA for the UE after the handover.

22. The method of claim 21, wherein: The ICN router is the ICN-PoA, and the method further comprises: In response to determining that the ICN-PoA is to be used if the UE is connected to the target RAN, determining that an update of at least one of a pending interest table (PIT) or a forwarding information base (FIB) table is to be performed in the ICN-PoA; and At least one of a PIT update indication or a FIB table update indication is encoded as the update indication for the ICN-PoA, the at least one of the PIT update indication or the FIB table update indication including a name of the ICN-PoA to be updated in the at least one of the PIT or the FIB table.

23. The method of claim 22, wherein the method further comprises determining the update of the at least one of the PIT or FIB table: If the UE is a consumer, only the incoming aspect of the PIT for interest packets sent by the UE; and If the UE is a producer, it is only the outgoing aspect of the FIB table for data packets to be forwarded to the UE.

24. The method of claim 19, wherein the triggered route update message indicates the UE and a source ICN-PoA, a target ICN-PoA, and an ICN gateway (ICN-GW) that is a waypoint capable of reaching the UE.

25. The method of claim 24, further comprising encoding the triggering routing update message to a plurality of ICN routers, and decoding a routing update acknowledgment from each of the ICN routers whose routing tables have been updated.

26. The method of claim 19, further comprising: determining that the ICN context information update request has been received from a target ICN-AMF, the target ICN-AMF being different from a source ICN-AMF associated with the UE stored in a memory of the ICN-CF; In response to determining that the ICN context information update request has been received from the target ICN-AMF, determining routing information to be updated in each of a plurality of ICN routers in the 5G network to communicate with the UE; as well as A triggered routing update message including the routing information is encoded for transmission to each of the plurality of ICN routers.

27. The method according to claim 26, in, The method further comprises determining a target ICN point of attachment ICN-PoA to which the UE is to be attached based on the target RAN; and The routing information includes an update to at least one of a pending interest table PIT or a forwarding information base FIB table, and the update includes the target ICN-PoA that the ICN router will update in the at least one of the PIT or the FIB table.

28. The method according to claim 27, wherein the method further comprises: decoding a routing update acknowledgment from each of the ICN routers whose routing tables have been updated; Determining whether the routing table in each of the ICN routers in the 5G network has been updated; as well as In response to determining that the routing table in each of the ICN routers in the 5G network has been updated, a confirmation encoding that the routing table in each of the ICN routers in the 5G network has been updated to communicate with the UE is transmitted to the target AMF.

29. A method for communication, comprising: Through information-centric networking ICN routers: decoding a triggered routing update message from an ICN control function ICN-CF, the triggered routing update message instructing a user equipment UE to switch from a source radio access node RAN to a target RAN; In response to receiving the triggered route update message, updating at least one of aspects of a pending interest table PIT or aspects of a forwarding information base FIB table to enable data communication with the UE after the handover, wherein only incoming aspects of the PIT for interest packets sent by the UE are updated when the UE is a consumer, and only outgoing aspects of the FIB table for data packets to be forwarded to the UE are updated when the UE is a producer; and In response to the updating of the at least one of the PIT or FIB table, encoding for transmission to the ICN-CF a confirmation that the at least one of the PIT or FIB table has been updated.

30. The method according to claim 29, wherein the triggered route update message includes a UE identity ID of the UE and a target RAN ID of the target RAN.

31. The method according to claim 30, wherein the triggering route update message further comprises identifiers of a source ICN point of attachment ICN-PoA to which the UE is connected before the handover and a target ICN-PoA to which the UE is to be connected after the handover.

32. The method of claim 31 further comprising: determining whether the source ICN-PoA serves at least one UE other than the UE; as well as If the source ICN-PoA serves the at least one UE, the at least one of the PIT or the FIB table is updated to enable data communication with the UE and the at least one UE other than the UE.

33. The method according to claim 31, wherein the triggering route update message further includes an identification of an ICN gateway (ICN-GW) which is a waypoint capable of reaching the UE.

34. The method of claim 29, wherein the handover is an N2-based handover because there is no Xn interface between the source RAN and the target RAN.

35. A non-transitory computer-readable storage medium having stored thereon instructions executable by a processor to cause the operations of the method of any one of claims 19 to 28 to be performed.

36. A non-transitory computer-readable storage medium having stored thereon instructions executable by a processor to cause the operations of the method of any one of claims 29 to 34 to be performed.

37. A computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method according to any one of claims 19 to 28.

38. A computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method according to any one of claims 29 to 34.

Images