Apparatus, method, and computer program product for communication

Abstract

The invention relates to an apparatus, a method and a computer program. A data storage apparatus comprising means for storing one or more timers in one or more timer stores of the data storage apparatus, the timers being associated with data used by a stateless consumer network function or a state-efficient consumer network function; monitoring the one or more timers; and in response to a trigger associated with a first timer of the one or more timers, causing a notification to be sent to a consumer network function of the first timer.

Description

Technical Field

[0001] This disclosure relates to apparatus, methods, and computer programs for data storage. Background Technology

[0002] A communication system can be viewed as a facility that enables a communication session between two or more entities, such as user terminals, base stations / access points, and / or other nodes, by providing carrier waves between various entities involved in the communication path. The communication system can be provided, for example, by means of a communication network and one or more compatible communication devices. The communication session can include, for example, data communication for carrying communications such as voice, email, text messages, multimedia, and / or content data. Non-limiting examples of the services provided include two-way or multiplexed calls, data communication or multimedia services, and access to data network systems such as the Internet. In a wireless communication system, at least a portion of the communication session between at least two stations occurs via a wireless link.

[0003] Users can access the communication system using suitable communication equipment or terminals. The user's communication equipment is typically called user equipment (UE) or user gear. The communication equipment is provided with suitable signal receiving and transmitting means to enable communication, for example, to enable access to a communication network or direct communication with other users. The communication equipment can access a carrier provided by a station or access point and transmit and / or receive communication on that carrier.

[0004] Communication systems and associated equipment typically operate according to required standards or specifications, which define what the various entities associated with the system are allowed to do and how this should be achieved. The communication protocols and / or parameters that should be used for connectivity are also usually defined. One example of a communication system is UTRAN (3G radio). Another example is the architecture known as Long Term Evolution (LTE) or Universal Mobile Telecommunications System (UMTS) radio access technology. Yet another example of a communication system is the so-called 5G radio or New Radio (NR) access technology. Summary of the Invention

[0005] According to one example, a data storage device is provided, including components for: storing one or more timers in one or more timer repositories of the data storage device, the timers being associated with data used by a stateless consumer network function or a stateful efficient consumer network function; monitoring the one or more timers; and, in response to a trigger associated with a first timer of the one or more timers, causing a notification to be sent to the consumer network function of the first timer.

[0006] This component can be used to store status information for one or more communication devices, which is used by one or more network function consumers.

[0007] Triggers may include one of the following: the expiration of the first timer; the change of the first timer; and the deletion of the first timer.

[0008] This component can be used to store subscriptions for a first timer, which instructs the network function consumer of the first timer to be notified of which triggers(s).

[0009] This component can be used to store a callback reference for a first timer, which indicates one or more network function consumers to which a notification is to be sent.

[0010] The first timer repository in the timer repository has one or more timers and is associated with a specific record related to the state of the communication device.

[0011] This component can be used to delete the timer in the first timer repository in the timer repository when a specific associated record is deleted.

[0012] This component can be used to create, modify, or delete timers in the first timer repository in the timer repository in response to a request received from a consumer network function indicating a specific associated record.

[0013] The second timer repository in the timer repository contains one or more timers required for handling stateless consumer network functions or stateful efficient consumer network functions.

[0014] The second timer repository in the timer repository is stored in the timer repository located directly under the domain and storage device.

[0015] The second timer repository in the timer repository contains timers for one or more non-call processing related activities of the communication device.

[0016] This component can be used to create, modify, or delete timers in a second timer repository in a timer repository in response to a request received from a network function consumer indicating an associated timer resource.

[0017] This component can be used to receive a search request for information about one or more timers from a network function consumer, perform a search based on the search request to provide search results including information about one or more timers, and provide a response including the search results.

[0018] Search requests may include filters, and search results may include information about one or more timers that satisfy the filters, including one or more of the timer status and metadata tags associated with the timer.

[0019] Data storage devices may include unstructured data storage capabilities.

[0020] According to another example, an apparatus for a consumer-side network function is provided, including components for: receiving a notification from a data storage device, the notification including information about a trigger associated with a first timer, the first timer being associated with data used by the consumer-side network function, the consumer-side network function including a stateless consumer-side network function or a stateful efficient consumer-side network function.

[0021] The timer can be associated with the state used by the consumer network function.

[0022] Triggers may include one of the following: the expiration of the first timer; the change of the first timer; and the deletion of the first timer.

[0023] This component can be used to subscribe to one or more triggered notifications associated with a first timer.

[0024] This component can be used to provide a callback reference for the first timer that identifies the consumer's network function.

[0025] The first timer type can be associated with a specific record related to the state of the communication device.

[0026] This component can be used to send a request to create, modify, or delete a timer of a first type, the request indicating a specific record associated with the first timer type.

[0027] Handling stateless consumer network functions or state-efficient consumer network functions may require a second timer type.

[0028] The second timer type can be used for one or more non-call processing related activities of the communication device.

[0029] This component can be used to send a request to create, modify, or delete a second type of timer, the request indicating the associated timer resource.

[0030] This component can be used to send a search request for information about one or more timers to a data storage device, and to receive a response including the search results.

[0031] Search requests may include filters, and search results may include information about one or more timers that satisfy the filters, including one or more of the timer status and metadata tags associated with the timer.

[0032] Data storage devices may include unstructured data storage capabilities.

[0033] According to one aspect, a data storage device is provided, including at least one processor and at least one memory, the at least one memory including computer code for one or more programs, the at least one memory and the computer code being configured, together with the at least one processor, to enable the device to at least: store one or more timers in one or more timer repositories of the data storage device, the timers being associated with data used by a stateless consumer network function or a stateful efficient consumer network function; monitor the one or more timers; and, in response to a trigger associated with a first timer of the one or more timers, cause a notification to be sent to the consumer network function of the first timer.

[0034] At least one memory and computer code may be configured, together with at least one processor, to enable the device to at least: store state information for one or more communication devices, the state being used by one or more network function consumers.

[0035] Triggers may include one of the following: the expiration of the first timer; the change of the first timer; and the deletion of the first timer.

[0036] At least one memory and computer code may be configured, together with at least one processor, to enable the device to at least: store a subscription for a first timer that indicates which or which network function consumers of the first timer should be notified of triggering.

[0037] At least one memory and computer code may be configured, together with at least one processor, to enable the device to at least: store a callback reference for a first timer, the callback reference indicating a notification to be sent to one or more network function consumers.

[0038] The first timer repository in the timer repository has one or more timers and is associated with a specific record related to the state of the communication device.

[0039] At least one memory and computer code can be configured, together with at least one processor, to cause the device to at least: delete a timer in a first timer repository in a timer repository when a specific associated record is deleted.

[0040] At least one memory and computer code can be configured, together with at least one processor, to enable the device to at least: create, modify, or delete a timer in a first timer repository in a timer repository in response to receiving a request from a consumer network function indicating a specific record associated therewith.

[0041] The second timer repository in the timer repository contains one or more timers required for handling stateless consumer network functions or stateful efficient consumer network functions.

[0042] The second timer repository in the timer repository is stored in the timer repository located directly under the domain and storage device.

[0043] The second timer repository in the timer repository contains timers for one or more non-call processing related activities of the communication device.

[0044] At least one memory and computer code can be configured, together with at least one processor, to enable the device to at least: create, modify, or delete a timer in a second timer repository in a timer repository in response to receiving a request from a network function consumer indicating an associated timer resource.

[0045] At least one memory and computer code may be configured, together with at least one processor, to enable the device to at least: receive a search request for information about one or more timers from a network function consumer, perform a search based on the search request to provide search results including information about one or more timers, and provide a response including the search results.

[0046] Search requests may include filters, and search results may include information about one or more timers that satisfy the filters, including one or more of the timer status and metadata tags associated with the timer.

[0047] Data storage devices may include unstructured data storage capabilities.

[0048] According to another example, an apparatus in a consumer-side network function is provided, the apparatus including at least one processor and at least one memory, the at least one memory including computer code for one or more programs, the at least one memory and the computer code being configured, together with the at least one processor, to enable the apparatus to at least: receive a notification from a data storage device, the notification including information about a trigger associated with a first timer, the first timer being associated with data used by the consumer-side network function, the consumer-side network function including a stateless consumer-side network function or a stateful efficient consumer-side network function.

[0049] The timer can be associated with the state used by the consumer network function.

[0050] Triggers may include one of the following: the expiration of the first timer; the change of the first timer; and the deletion of the first timer.

[0051] At least one memory and computer code may be configured, together with at least one processor, to enable the device to at least: subscribe to notifications from one or more triggers associated with a first timer.

[0052] At least one memory and computer code can be configured, together with at least one processor, to enable the device to at least: provide a callback reference for a first timer that identifies the consumer network function.

[0053] The first timer type can be associated with a specific record related to the state of the communication device.

[0054] At least one memory and computer code may be configured, together with at least one processor, to cause the device to at least: send a request to create, modify, or delete a timer of a first type, the request indicating a specific record associated with the first timer type.

[0055] Handling stateless consumer network functions or stateful efficient consumer network functions may require a second timer type.

[0056] The second timer type can be used for one or more non-call processing related activities of the communication device.

[0057] At least one memory and computer code can be configured, together with at least one processor, to cause the device to at least: cause a request to be sent to create, modify, or delete a second type of timer, the request indicating an associated timer resource.

[0058] At least one memory and computer code can be configured, together with at least one processor, to cause the device to at least: send a search request for information about one or more timers to a data storage device, and receive a response including the search results.

[0059] Search requests may include filters, and search results may include information about one or more timers that satisfy the filters, including one or more of the timer status and metadata tags associated with the timer.

[0060] Data storage devices may include unstructured data storage capabilities.

[0061] According to another example, a data storage device is provided, including a circuit system configured to: store one or more timers in one or more timer repositories of the data storage device, the timers being associated with data used by a stateless consumer network function or a stateful efficient consumer network function; monitor the one or more timers; and, in response to a trigger associated with a first timer of the one or more timers, cause a notification to be sent to the consumer network function of the first timer.

[0062] The device may include a circuit system configured to store status information for one or more communication devices, the status of which is used by one or more network function consumers.

[0063] Triggers may include one of the following: the expiration of the first timer; the change of the first timer; and the deletion of the first timer.

[0064] The apparatus may include a circuit system configured to store a subscription for a first timer that indicates which or which network function consumers of the first timer should be notified of triggering.

[0065] The device may include a circuit system configured to store a callback reference for a first timer, the callback reference indicating a notification to be sent to one or more network function consumers.

[0066] The first timer repository in the timer repository has one or more timers and is associated with a specific record related to the state of the communication device.

[0067] The device may include a circuit system configured to delete a timer in a first timer repository when a specific associated record is deleted.

[0068] The device may include a circuit system configured to create, modify, or delete a timer in a first timer repository in a timer repository in response to receiving a request from a consumer network function indicating a specific associated record.

[0069] The second timer repository in the timer repository contains one or more timers required for handling stateless consumer network functions or stateful efficient consumer network functions.

[0070] The second timer repository in the timer repository is stored in the timer repository located directly under the domain and storage device.

[0071] The second timer repository in the timer repository contains timers for one or more non-call processing related activities of the communication device.

[0072] The device may include a circuit system configured to create, modify, or delete timers in a second timer repository in a timer repository in response to receiving a request from a network function consumer indicating an associated timer resource.

[0073] The device may include a circuit system configured to: receive a search request from a network function consumer for information about one or more timers; perform a search based on the search request to provide search results including information about one or more timers; and provide a response including the search results.

[0074] Search requests may include filters, and search results may include information about one or more timers that satisfy the filters, including one or more of the timer status and metadata tags associated with the timer.

[0075] Data storage devices may include unstructured data storage capabilities.

[0076] According to another example, an apparatus in a consumer network is provided, including a circuit system configured to receive a notification from a data storage device, the notification including information about a trigger associated with a first timer, the first timer being associated with data used by a consumer network function, the consumer network function including a stateless consumer network function or a stateful efficient consumer network function.

[0077] The timer can be associated with the state used by the consumer network function.

[0078] Triggers may include one of the following: the expiration of the first timer; the change of the first timer; and the deletion of the first timer.

[0079] The device may include a circuit system configured to subscribe to notifications from one or more triggers associated with a first timer.

[0080] The device may include a circuit system configured to provide a callback reference for a first timer that identifies the consumer network function.

[0081] The first timer type can be associated with a specific record related to the state of the communication device.

[0082] The device may include a circuit system configured to send a request to create, modify, or delete a timer of a first type, the request indicating a specific record associated with the first timer type.

[0083] Handling stateless consumer network functions or stateful efficient consumer network functions may require a second timer type.

[0084] The second timer type can be used for one or more non-call processing related activities of the communication device.

[0085] The device may include a circuit system configured such that a request is sent to create, modify, or delete a second type of timer, the request indicating an associated timer resource.

[0086] The device may include a circuit system configured to send a search request for information about one or more timers to a data storage device; and to receive a response including the search results.

[0087] A search request may include filters, and the search results may include information about one or more timers that satisfy the filters, including one or more of the timer status and metadata tags associated with the timer.

[0088] Data storage devices may include unstructured data storage capabilities.

[0089] According to one example, a method is provided, comprising: storing one or more timers in one or more timers associated with data used by a stateless consumer network function or a stateful efficient consumer network function; monitoring the one or more timers; and causing a notification to be sent to a consumer network function of the first timer in response to a trigger associated with a first timer of the one or more timers.

[0090] A time repository can be provided in a data storage device.

[0091] This method can be executed by a data storage device.

[0092] The method may include storing status information of one or more communication devices, the status of which is used by one or more network function consumers.

[0093] Triggers may include one of the following: the expiration of the first timer; a change to the first timer; or the deletion of the first timer.

[0094] The method may include storing a subscription to a first timer that indicates which or which network function consumers of the first timer will be notified to trigger.

[0095] The method may include storing a callback reference for a first timer that indicates one or more network function consumers to which a notification will be sent.

[0096] The first timer repository in the timer repository can have one or more timers and be associated with a specific record related to the state of the communication device.

[0097] This method may include deleting a timer from the first timer repository in the timer repository when a specific associated record is deleted.

[0098] The method may include: in response to receiving a request from a consumer network function indicating a specific record associated therewith, creating, modifying, or deleting a timer in a first timer repository in a timer repository.

[0099] The second timer repository in the timer repository can have one or more timers required to handle stateless consumer network functions or stateful efficient consumer network functions.

[0100] The second timer repository in the timer repository can be located directly in the timer repository under the domain and storage device.

[0101] The second timer repository in the timer repository can have timers for one or more non-call processing related activities of the communication device.

[0102] The method may include: in response to receiving a request from a network function consumer indicating an associated timer resource, creating, modifying, or deleting a second timer repository in the timer repository.

[0103] The method may include receiving a search request from a network function consumer for information about one or more timers, performing a search based on the search request to provide search results including information about one or more timers, and providing a response including the search results.

[0104] A search request may include filters, and the search results may include information about one or more timers that satisfy the filters, including one or more of the timer status and metadata tags associated with the timer.

[0105] Data storage devices may include unstructured data storage capabilities.

[0106] According to another example, a method is provided, the method comprising: receiving from a data storage device a notification including information about a trigger associated with a first timer, the first timer being associated with data used by a consumer network function, the consumer network function including a stateless consumer network function or a stateful efficient consumer network function.

[0107] The timer can be associated with the state used by the consumer network function.

[0108] Triggers may include one of the following: the expiration of the first timer; a change to the first timer; or the deletion of the first timer.

[0109] This method may include subscribing to one or more triggered notifications associated with a first timer.

[0110] This method may include providing a callback reference for the first timer to identify the consumer network function.

[0111] The first timer type can be associated with a specific record related to the state of the communication device.

[0112] The method may include causing a request to be sent to create, modify, or delete a timer of a first type, the request indicating a specific record associated with the first timer type.

[0113] Handling stateless consumer network functions or stateful efficient consumer network functions may require a second timer type.

[0114] The second timer type can be used for one or more non-call processing related activities of the communication device.

[0115] The method may include causing a request to be sent to create, modify, or delete a second type of timer, the request indicating an associated timer resource.

[0116] The method may include: sending a search request for information about one or more timers to a data storage device; and receiving a response including the search results.

[0117] A search request may include filters, and the search results may include information about one or more timers that satisfy the filters, including one or more of the timer status and metadata tags associated with the timer.

[0118] Data storage devices may include unstructured data storage capabilities.

[0119] According to another example, a computer program including computer-executable code is provided, which, when running on at least one processor, is configured to: store one or more timers in one or more timer repositories of a data storage device, the timers being associated with data used by a stateless consumer network function or a stateful efficient consumer network function; monitor the one or more timers; and, in response to a trigger associated with a first timer of the one or more timers, cause a notification to be sent to the consumer network function of the first timer.

[0120] The computer program may include computer-executable code configured to, when run on at least one processor, store status information of one or more communication devices, the status of which is used by one or more network function consumers.

[0121] Triggers can include the expiration of the first timer; changes to the first timer; and deletion of the first timer.

[0122] The computer program may include computer-executable code configured to, when running on at least one processor, store a subscription to a first timer, the subscription indicating which or which network function consumers of the first timer will be notified to trigger.

[0123] The computer program may include computer-executable code configured, when running on at least one processor, to store a callback reference for a first timer that indicates one or more network function consumers to which the notification is to be sent.

[0124] The first timer repository in the timer repository can have one or more timers and be associated with a specific record related to the state of the communication device.

[0125] The computer program may include computer-executable code configured, when running on at least one processor, to delete a timer in a first timer repository in a timer repository when a specific associated record is deleted.

[0126] The computer program may include computer-executable code configured, when running on at least one processor, to: create, modify, or delete a timer in a first timer repository in a timer repository in response to receiving a request from a consumer network function indicating a specific record associated therewith.

[0127] The second timer repository in the timer repository can have one or more timers required to handle stateless consumer network functions or stateful efficient consumer network functions.

[0128] The second timer repository in the timer repository can be located directly in the timer repository under the domain and storage device.

[0129] The second timer repository in the timer repository can have timers for one or more non-call processing related activities of the communication device.

[0130] The computer program may include computer-executable code configured, when running on at least one processor, to: create, modify, or delete a timer in a second timer repository in a timer repository in response to receiving a request from a network function consumer indicating an associated timer resource.

[0131] The computer program may include computer-executable code configured, when running on at least one processor, to: receive a search request from a network function consumer for information about one or more timers; perform a search based on the search request to provide search results including information about one or more timers; and provide a response including the search results.

[0132] A search request may include filters, and the search results may include information about one or more timers that satisfy the filters, including one or more of the timer status and metadata tags associated with the timer.

[0133] Data storage devices may include unstructured data storage capabilities.

[0134] According to another example, a computer program including computer-executable code is provided, which, when running on at least one processor, is configured to: receive from a data storage device a notification including information about a trigger associated with a first timer, the first timer being associated with data used by a consumer network function, the consumer network function including a stateless consumer network function or a stateful efficient consumer network function.

[0135] The timer can be associated with the state used by the consumer network function.

[0136] The trigger may include one of the following: the expiration of the first timer; the change of the first timer; or the deletion of the first timer.

[0137] The computer program may include computer-executable code configured, when running on at least one processor, to subscribe to one or more triggering notifications associated with a first timer.

[0138] The device may include a circuit system configured to provide a callback reference for identifying consumer network functions for a first timer.

[0139] The first timer type can be associated with a specific record related to the state of the communication device.

[0140] The computer program may include computer-executable code configured, when running on at least one processor, to cause a request to be sent to create, modify, or delete a timer of a first type, the request indicating a specific record associated with the first timer type.

[0141] Handling stateless consumer network functions or stateful efficient consumer network functions may require a second timer type.

[0142] The second timer type can be used for one or more non-call processing related activities of the communication device.

[0143] The computer program may include computer-executable code configured, when running on at least one processor, to cause a request to be sent to create, modify, or delete a second type of timer, the request indicating an associated timer resource.

[0144] The computer program may include computer-executable code configured, when running on at least one processor, to: send a search request for information about one or more timers to a data storage device; and receive a response including the search results.

[0145] A search request may include filters, and the search results may include information about one or more timers that satisfy the filters, including one or more of the timer status and metadata tags associated with the timer.

[0146] Data storage devices may include unstructured data storage capabilities.

[0147] According to another example, an application programming interface (API) for data storage functionality is provided, which includes a Uniform Resource Identifier (URI) structure, comprising, in the following order:

[0148] Domain identifier; storage device identifier and timer repository.

[0149] According to another example, an application programming interface (API) for data storage functionality is provided, which includes a Uniform Resource Identifier (URI) structure, comprising, in the following order:

[0150] Domain identifier; storage device identifier; record identifier; and timer repository.

[0151] According to one aspect, a computer-readable medium is provided, the computer-readable medium including program instructions stored thereon for performing at least one of the methods described above.

[0152] According to one aspect, a non-transient computer-readable medium is provided, the non-transient computer-readable medium including program instructions stored thereon for performing at least one of the methods described above.

[0153] According to one aspect, a non-volatile tangible storage medium is provided, the non-volatile tangible storage medium including program instructions stored thereon for performing at least one of the methods described above.

[0154] Many different aspects have been described above. It should be understood that additional aspects can be provided through any two or more combinations of the above aspects.

[0155] Various other aspects are also described in the following detailed description and the appended claims.

[0156] List of abbreviations

[0157] AF: Application Functions

[0158] AMF: Access Management Function

[0159] API: Application Protocol Interface

[0160] BS: Base Station

[0161] CNF: Cloud-based / Containarized Network Functions

[0162] CU: Centralized Unit

[0163] DL: Downlink

[0164] DU: Distributed Unit

[0165] eNB: eNodeB

[0166] GNB: gNodeB

[0167] GSM: Global System for Mobile Communications

[0168] GUTI: Globally Unique Temporary Identifier

[0169] HSS: Home Subscriber Server

[0170] IoT: Internet of Things

[0171] LTE: Long Term Evolution

[0172] MAC: Media Access Control

[0173] MS: Mobile Site

[0174] MTC: Machine Type Communication

[0175] NEF: Network Exposure Function

[0176] NF: Network Functions

[0177] NGAP: NG Application Protocol

[0178] NR: New Radio

[0179] NRF: Network Functions Storage Function

[0180] OAM: Operations Management and Maintenance

[0181] PDU: Packet Data Unit

[0182] RAM: Random Access Memory

[0183] (R)AN: (Radio) Access Network

[0184] ROM: Read-Only Memory

[0185] SMF: Session Management Function

[0186] S-NSSAI: Single network slice selection auxiliary information

[0187] SUCI: Subscriber Hidden Identifier

[0188] SUPI: Subscriber Permanent Identifier

[0189] TIMSI: Temporary Mobile Subscriber Identifier

[0190] TR: Technical Report

[0191] TS: Technical Specifications

[0192] TTL: Time to Live

[0193] UDSF: Unstructured Data Storage Function

[0194] UE: User Equipment

[0195] UMTS: Universal Mobile Telecommunications System

[0196] URI: Uniform Resource Identifier

[0197] 3GPP: 3rd Generation Partnership Project

[0198] 5G: 5th generation

[0199] 5GC: 5G Core Network

[0200] 5GS: 5G system Attached Figure Description

[0201] Embodiments will now be described by way of example only with reference to the accompanying drawings, in which:

[0202] Figure 1 A schematic diagram of a 5G system is shown;

[0203] Figure 2 A schematic diagram of the device is shown;

[0204] Figure 3A schematic diagram of a non-volatile storage medium is shown, which stores instructions that, when executed by a processor, allow the processor to perform one or more steps of a method of some embodiments;

[0205] Figure 4 A schematic diagram of the structure of the Uniform Resource Identifier (URI) of the Unstructured Data Storage Function (UDSF) application programming interface is shown.

[0206] Figure 5 A table is shown that provides the definitions of type record elements;

[0207] Figure 6 The resource URI structure of the UDSF API, including timer resources, is shown in some embodiments;

[0208] Figure 7 This is an overview of timer resources and methods in some embodiments.

[0209] Figure 8 A table is shown illustrating the definitions of type timer data structures that provide some embodiments;

[0210] Figure 9 The table shows definitions of type records, providing some embodiments to support tables associated with record timers;

[0211] Figure 10 A table of URI query parameters for some embodiments is shown;

[0212] Figure 11 The signaling diagram for the explicit creation of autonomous timers in UDSF is shown;

[0213] Figure 12 A signaling diagram for the explicit creation of additional timers in UDSF is shown;

[0214] Figure 13 The signaling diagram for recording the implicit creation of an additional timer in the UDSF is shown;

[0215] Figure 14 The signaling diagram for the modification of the autonomous timer in UDSF is shown;

[0216] Figure 15 The signaling diagram for recording modifications to the additional timer in the UDSF is shown;

[0217] Figure 16 The signaling diagram for autonomous timer acquisition in UDSF is shown;

[0218] Figure 17 The signaling diagram for recording additional timer acquisition in UDSF is shown;

[0219] Figure 18The signaling diagram for obtaining the additional timer list in UDSF is shown;

[0220] Figure 19 The signaling diagram for deleting an autonomous timer in UDSF is shown;

[0221] Figure 20 The signaling diagram for the deletion of multiple autonomous timers in UDSF is shown;

[0222] Figure 21 The signaling diagram for deleting a record-attached timer in UDSF is shown;

[0223] Figure 22 The signaling diagram for deleting multiple record-attached timers in UDSF is shown;

[0224] Figure 23 The signaling diagram for autonomous timer search in UDSF is shown;

[0225] Figure 24 The signaling diagram for record attachment timer search in UDSF is shown;

[0226] Figure 25 The signaling diagram for wildcard record additional timer search in UDSF is shown;

[0227] Figure 26 The signaling diagram for timer expiration notification is shown;

[0228] Figure 27 Tables with type subscription filter definitions are shown in some embodiments;

[0229] Figure 28 A table showing the definitions of timer type enumeration record operations supporting some embodiments is provided;

[0230] Figure 29 The signaling diagram for subscribing to timer resources is shown;

[0231] Figure 30 A table showing the recording notification types that support recording timers is provided.

[0232] Figure 31 A signaling diagram for recording notifications of additional timers is shown;

[0233] Figure 32 A table showing the types of notifications logged by the timer is provided;

[0234] Figure 33 The signaling diagram for the notification of the autonomous timer is shown;

[0235] Figure 34 Some example methods are shown; and

[0236] Figure 35 Some example methods are shown. Detailed Implementation

[0237] In the following explanation, certain embodiments are described with reference to mobile communication devices capable of communicating via wireless cellular systems and mobile communication systems serving such mobile communication devices. Before explaining the exemplary embodiments in detail, refer to... Figure 1 , Figure 2 and Figure 3 Briefly explain some general principles of wireless communication systems, their access systems, and mobile communication devices to help understand the technologies underlying the examples described.

[0238] Figure 1 A schematic diagram of a 5G system (5GS) is shown. 5GS may include terminals, a (radio) access network ((R)AN), a 5G core network (5GC), one or more application functions (AF), and one or more data networks (DN).

[0239] 5G (R)AN may include one or more gNodeB (gNB) distributed unit functions connected to one or more gNodeB (gNB) centralized unit functions.

[0240] 5G can be used for mobile or fixed access. 5GC may include Access Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), User Data Management (UDM), User Plane Function (UPF), and / or Network Exposure Function (NEF). Although not shown, 5GC may include other network functions (NFs), such as Unstructured Data Storage Function (UDSF).

[0241] Figure 2 An example of device 200 is illustrated. This device may include at least one memory. By way of example only, the memory may include random access memory (RAM) 211a and / or at least read-only memory (ROM) 211b. In other embodiments, the memory may alternatively or additionally be provided by any other suitable device. The device may include at least one processor 212, 213. The device may include an input / output interface 214. At least one processor may be coupled to said at least one memory. The at least one processor may be configured to execute suitable software code 215. The software code 215 may, for example, allow the execution of one or more steps to perform one or more of the aspects herein. The software code 215 may be stored in at least one memory. By way of example only, the software code may be stored in ROM 211b.

[0242] UDSF can include, for example Figure 2The apparatus shown includes a suitable data storage device. The data storage device may be provided by one or more databases or any other suitable data storage device.

[0243] Network function consumers may include, for example Figure 2 The apparatus shown.

[0244] One or more aspects of this disclosure relate to the Nudsf_DataRepository service application programming interface (API). The Nudsf_DataRepository service API is standardized in Rel-16 and defines how UDSF service consumers can store and retrieve unstructured data in UDSF.

[0245] According to TS29.598, data in the UDSF can be placed in records. Each record can have a record identifier (record ID). Each record can correspond to, for example, a UE. Each record may not include blocks, or may include one or more blocks. For example, a record may include a mobility management block and / or a session management block. Each block may include content with arbitrary structure. The UDSF is unaware of the content and structure of the blocks(s). Each record may include record metadata (i.e., record metadata).

[0246] When a UDSF service consumer knows the record ID, storing and retrieving records in UDSF can be very efficient. However, in many cases, the UDSF service consumer does not know the record ID (e.g., in situations where a stateless NF must serve a request). In such cases, the UDSF consumer may first have to perform a search for records in UDSF based on GET query parameters applied as metadata filters. These filters can be record metadata elements (IEs). Record metadata filters are tag-based.

[0247] Record meta tags are mappings of tag name / value pairs. To facilitate searching within tags, the meta-pattern feature was introduced in Rel-16. When a meta-pattern is supported by both the UDSF and NF consumer, the NF consumer can store the meta-pattern in the UDSF and link the record's meta tag to the stored meta-pattern. The linked meta-pattern indicates the intended use of each tag, such as as a unique search key, search key, counter key, or other key. The meta-pattern feature treats all tags as strings.

[0248] Each record can have a single "ttl" (validity time) timer associated with it. This timer refers to the storage validity period of the record. After the time indicated by tt1 has elapsed, the record is deleted.

[0249] Some embodiments relate to efficient storage, searching, and / or retrieval of tags in the UDSF. Some embodiments can trigger a notification after the tag expires.

[0250] Figure 4 This diagram illustrates a schematic representation of the Uniform Resource Identifier (URI) for resources according to the UDSF application programming interface of TS29.598 v 16.3.0. The UDSF API includes record elements for the meta schema and the schema ID (schema ID) that references the meta schema.

[0251] Figure 5 A table is shown that provides the definition of type record elements according to TS29.598 v 16.3.0.

[0252] Record elements can include label attributes. A label is a mapping between a label name and one or more label values. The label name is a unique string name that serves as the map's primary key. The one or more label values ​​can be an array of string values.

[0253] Record elements can include a time-to-live (TTL) timer attribute. TTL refers to the record's validity period. The record is deleted after the TTL timer expires.

[0254] Record elements can include callback reference attributes. The callback reference includes a URI in which the NF service consumer can receive notifications about TTL timer expiration.

[0255] Record metadata may include a reference to a pattern ID. The pattern ID includes the ID of the meta-pattern to which the tag conforms.

[0256] Some implementations provide one or more timers to manage tag expiration. Stateless network functions or state-efficient NFs operating within an NF set may need to store and retrieve timers from the UDSF. These timers may be related to UE state and / or other non-UE call processing activities.

[0257] Currently, there is no standardized solution for how UDSF consumers can store and monitor the expiration of these timers in order to trigger appropriate actions when the timers expire. In the absence of timer-specific support in the UDSF, the responsibility for monitoring timer expiration rests with the consumer. For example, the consumer can use external triggers to poll or periodically poll the UDSF for records related to the stored timers.

[0258] The existing UDSF record resource structure and API can be used to store timers.

[0259] UDSF consumers can implicitly store timers as strings within records by adding tags to the metadata. In this case, the consumer can then search / polulate the "timer". In some cases, this can provide inefficient searching because the meta-pattern treats timestamp values ​​as normal strings. The key-value pairs used in the record metadata do not support timer-specific logic, such as issuing notifications after expiration. Polling may not have the required timing precision because the timer may have already expired when the record is retrieved.

[0260] Some implementations may provide a UDSF API, which allows timers to be explicitly stored and disposed of by UDSF as a separate resource. NF consumers can use the UDSF API to efficiently poll expiring timers and / or be notified after a timer expires.

[0261] Some embodiments may provide a timer resource structure to the UDSF API. Some embodiments will provide operations designed to store, retrieve, and / or search timers. Some embodiments will provide operations designed to store, retrieve, and / or search timers and trigger timer-related notifications.

[0262] Some implementations can support the correlation between timers and records.

[0263] Some embodiments may provide one or more timers. Information about the timers may be stored in the UDSF.

[0264] In some embodiments, two types of timers may be supported. It should be understood that in other embodiments, only one of these two types of timers may be supported.

[0265] The timer can be an "autonomous" timer or a "record attached" timer.

[0266] The autonomous timer is not explicitly associated with the recording. In this regard, refer to... Figure 6 , Figure 6 The timer pair using some embodiments is shown. Figure 4 Modification of the API resource URI structure. Autonomous timers can be stored under a timer repository, which resides directly under a realm and storage device. See 600 for details.

[0267] Record-attached timers are associated with a specific record. A record can have zero, one, or more timers. In some embodiments, each timer can have only one record to which it belongs. Record-attached timers are stored under the associated repository within the record. See also... Figure 6 602 in the middle.

[0268] Operations on autonomous timers can be defined within timer-related services (such as the Nudsf_Timer service) or extensions to the Nudsf_datarepository service. Operations on record-attached timers can be defined as extensions to the Nudsf_data_repository service.

[0269] Figure 7 An outline of the resources and methods of some embodiments is shown. It should be understood that some embodiments may use only one of these resources and one method, while some embodiments may use two or more, or all of these resources and two or more, or all of these methods. This will be described in more detail later. Figure 7 The table shows the resources and methods.

[0270] Figure 8 The timer data structure used in some embodiments is shown.

[0271] Each timer has an expiration time stored in the expiration field.

[0272] In some embodiments, a timer may have one or more of the following properties:

[0273] • Meta tags. These are mappings of tag name / value pairs. The tag name is a unique string name that serves as the primary key of the mapping and is paired with an array of string values. These tags can be used as timer attributes. Tags can be used for search operations.

[0274] • Callback Reference: This is the URI in which the NF service consumer receives a notification after the timer expires.

[0275] • After deletion: If specified, the timer resource will be deleted after a period of several seconds following its expiration time, defined by the value after deletion. If not specified, the timer can be deleted immediately after its expiration time, or after the default amount of time.

[0276] • Schema ID: An optional reference to the ID of the meta-pattern that the timer's meta tag matches. This can be used to optimize timer search based on their meta tags.

[0277] Alternatively, in some embodiments, the timer ID can be provided as the IE within the timer data structure. In this example, the timer ID can be the same as the ID used in the resource URI path.

[0278] To support recording additional timers, record data types utilize, such as... Figure 9 The timer mapping shown in the table is expanded. The table displays attribute meta-attributes, blocks, and timers. Meta-attributes are the meta-attributes of a record. Block attributes are the blocks (if any) that make up a record. Timer attributes are mappings where the key to the mapping is the timer ID. This timer ID is unique for the contained records, and the value of each item in the mapping is the timer data.

[0279] In some embodiments, a timer can be created. A timer can be modified. A timer can be deleted.

[0280] In some embodiments, autonomous timers can be created or updated via the PUT method in the timers resource store.

[0281] In some embodiments, an autonomous timer can be deleted via the DELETE method on the timer.

[0282] In some embodiments, one or more autonomous timer stores can be deleted via the DELETE method in the timer resource.

[0283] In some embodiments, a record-attached timer can be implicitly created or modified on a record resource via the associated PUT method.

[0284] In some embodiments, record-attached timers can be explicitly created or modified via the associated PUT method on the record timer repository within the record.

[0285] In some embodiments, a timer for an additional record can be implicitly deleted by deleting the entire record via a DELETE operation.

[0286] In some embodiments, a timer with an attached record can be explicitly deleted on a timer in a record timer repository via the DELETE method.

[0287] In some embodiments, recording timers can be deleted from the entire recording timer repository via a deletion method.

[0288] In some embodiments, a timer can be obtained via a GET operation on the relevant timer resource. A record-attached timer can be obtained by retrieving a record that contains the record-attached timer.

[0289] The autonomous timer can be obtained through the following path:

[0290] / {realmId} / {storageId} / timers / {timerId}).

[0291] The attached timer can be obtained through the following path:

[0292] / {realmId} / {storageId} / records / {recordId} / timers {timerId}.

[0293] Some implementations can support searching for timers. UDSF service consumers can send requests to UDSF to search for timers filtered by provided "filter" query parameters. This operation can support one or both of autonomous timers and recorded additional timers.

[0294] In some embodiments, a query parameter option "Timer Status" is provided in the search operation used for timers to support searches based on timer expiration status and / or any other appropriate status. In this regard, see [reference]. Figure 10 The table shows the URI query parameters used to search for the timer, which are supported by the GET method.

[0295] In some embodiments, the timer status parameter can be applied to and included in a timer search. If the parameter is set to EXPIRED in the search, the search results will return expired timers. If the parameter is set to NON_EXPIRED, the search results will return unexpired timers. If the parameter is set to ANY, the search results will return both expired and unexpired timers. When searching for timers and the parameter is not present, the value ANY can be assumed by default.

[0296] Searches for autonomous timers can be sent to / {realmId} / {storageId} / timerstore.

[0297] Searches for timers attached to a record can be sent to the / {realmId} / {storageId} / storageId} / records store. The presence of a timer state indicates that the search is for the timer repository within the record, and the filter is applied to the record element of the timer rather than the record itself.

[0298] In some embodiments, a search for a record of an additional timer can be sent to / {realmId} / {storageId}. . This indicates a wildcard search used instead of a specific record ID.

[0299] In some embodiments, when the timer expires, the UDSF will notify the NF consumer by sending a relevant notification to a given callback reference.

[0300] In some embodiments, NF can create subscriptions for timers to receive notifications of timer changes, timer deletions, and / or timer expirations via an extension of the subscription / notification mechanism used for recording.

[0301] The creation or modification (e.g., replacement) of explicit autonomous timers in some embodiments will now be described. NF users can explicitly create or modify autonomous timers on / {realmId} / {storageId} / timers / {timerId}, which provides the timer ID, via the HTTP PUT method. The PUT method allows stateless NF consumers to deduce the timer ID from the context. As an example only, this can be done using a formula based on UE SUPI.

[0302] refer to Figure 11 It illustrates the call flow for explicitly creating an autonomous timer in UDSF.

[0303] In step 1: The NF service consumer (any NF) sends a PUT request to create a timer indicated by a timer ID. The request body contains the autonomous timer to be created. Information about the timer to be created can be provided. This information may include the specified expiration time. Optionally, additional information such as meta tags and / or callback information may be provided.

[0304] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "201 Created" message.

[0305] If unsuccessful, in step 2b, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a PUT response message. Error information may be provided in the PUT response body.

[0306] The creation or modification (e.g., replacement) of record-attached timers in some embodiments will now be described. An NF consumer can explicitly create or modify record-attached timers on the resource / {realmId} / {storageId} / records / {recordId} / timers / {timerId}, which provides the timer ID, via the HTTP PUT method.

[0307] refer to Figure 12 It illustrates the call flow used to record the explicit creation of associated timers in UDSF.

[0308] In step 1: The NF service consumer (any NF) sends a PUT request to create or update a record-associated timer indicated by the record ID and timer ID. Information about the timer to be created can be provided. This information may include the specified expiration time. Optionally, additional information such as meta tags and / or callback information may be provided.

[0309] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "201 Created" message.

[0310] If unsuccessful, in step 2b, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a PUT response message. Error information may be provided in the PUT response body.

[0311] This method can be used when the record referenced by the record ID already exists in a given region and storage device.

[0312] If the attached timer is being replaced, the PUT request can be a timer replacement request. In the replacement case, the response code will be 204 No Content.

[0313] The creation or modification (e.g., replacement) of implicit record-attached timers in some embodiments will now be described. An NF consumer can implicitly create or modify a timer on the resource / {realmId} / {storageId} / records / {recordId} via the HTTP PUT method. This resource includes the timer associated with the record within the record body.

[0314] refer to Figure 13 , Figure 13 The call flow for implicitly creating a record-associated timer in UDSF is shown.

[0315] In step 1: The NF service consumer (any NF) sends a PUT request to create or update a record-associated timer indicated by the record ID. The request body record contains the record-attached timer to be created or updated accordingly.

[0316] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "201 Created" message.

[0317] If unsuccessful, in step 2b, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a PUT response message. Error information may be provided in the PUT response body.

[0318] The autonomous timer modification of some embodiments will now be described. NF consumers can explicitly create or modify autonomous timers via the HTTP PATCH method on the timer ID provided in the patch item and on / {realmId} / {storageId} / timers / {timerId}.

[0319] refer to Figure 14 , Figure 14 The call flow for modifying the autonomous timer in UDSF is shown.

[0320] In step 1: The NF service consumer (any NF) sends a PATCH request to modify the timer indicated by the timer ID. The request body contains the autonomous timer to be modified.

[0321] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "204 No Content" message.

[0322] If the record does not exist, in step 2b, the UDSF returns a message indicating this to the NF consumer. This message may be a "404 Not Found" HTTP status code.

[0323] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a PATCH response message. Error information may be provided in the PATCH response body.

[0324] Some variations of the record-attached timer from these embodiments will now be described. NF consumers can explicitly create or modify autonomous timers via the HTTP PATCH method, using the timer ID provided in the patch entry and the modified ` / {realmId} / {storageId} / records / {recordId} / timers / {timerId}`. The following diagram illustrates an exemplary call flow:

[0325] refer to Figure 15 , Figure 15 The call flow for modifying the record attachment timer in UDSF is shown.

[0326] In step 1: The NF service consumer (any NF) sends a PATCH request to modify the timer indicated by the timer ID. The request body contains the autonomous timer to be modified.

[0327] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "204 No Content" message.

[0328] If the record does not exist, in step 2b, the UDSF returns a message to the NF consumer indicating this. This message may be a "404 Not Found" HTTP status code.

[0329] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a PATCH response message. Error information may be provided in the PATCH response body.

[0330] NF consumers can request auto-timers from the relevant resources ( / {realmId} / {storageId} / timers / {timerId}) via the HTTP GET method.

[0331] refer to Figure 16 , Figure 16 The call flow for requesting to obtain an autonomous timer is shown.

[0332] In step 1: The NF service consumer (any NF) sends a GET request to the timer resource indicated by the timer ID.

[0333] If successful, in step 2a, the UDSF returns a success message, such as a "200 OK" message, to the NF consumer. The message body may contain a timer.

[0334] If the timer with the given timer ID does not exist in the UDSF, then in step 2b, the UDSF will return a message indicating this to the NF consumer. This message may be a "404 Not Found" HTTP status message.

[0335] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a GET response message. Error information may be provided in the GET response body.

[0336] NF consumers can use the HTTPGET method to retrieve the attached timer for a specific record from the relevant timer resource ( / {real_Id} / {storage_Id} / records / {record_Id}timers / {timer_Id}).

[0337] refer to Figure 17 , Figure 17 The call flow for requesting a record-specific timer is shown.

[0338] In step 1: The NF service consumer (any NF) sends a GET request to the timer resource indicated by the timer ID.

[0339] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "200 OK" message. The message body may contain a timer.

[0340] If the timer with the given timer ID does not exist in the UDSF, then in step 2b, the UDSF will return a message indicating this to the NF consumer. This message may be a "404 Not Found" HTTP status message.

[0341] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a GET response message. Error information may be provided in the GET response body.

[0342] NF consumers can obtain a complete list of record-associated timers ( / {realmId} / {storageId} / records / {recordId} / timers}) via an HTTP GET method on the timer repository within the record.

[0343] refer to Figure 18 , Figure 18 The call flow for requesting to retrieve a timer associated with a specific record is shown.

[0344] In step 1: The NF service consumer (any NF) sends a GET request to the timer repository in the record.

[0345] If successful, in step 2a, the UDSF returns a success message, such as a "200 OK" message, to the NF consumer. The message body may contain timers. The message body may contain mappings with timers.

[0346] If a given record does not exist, or if a timer resource for the given record does not exist in the UDSF, then in step 2b, the UDSF returns a message to the NF user indicating this. If the specified record does not exist, this message can be a "404 Not Found" HTTP status message. If the record does exist but there is no timer, the status code used can depend on whether {recordId} / timer / resource has been created but is empty, or {recordId} / timer / does not exist.

[0347] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a GET response message. Error information may be provided in the GET response body.

[0348] NF consumers can delete autonomous timers from the relevant timer repository ( / {realmId} / {storageId} / timers / {timerId}) using the HTTP DELETE method.

[0349] refer to Figure 19 , Figure 19 The call flow for removing a single autonomous timer in UDSF is shown.

[0350] In step 1: The NF service consumer (any NF) sends a DELETE request to the timer resource indicated by the timer ID.

[0351] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "204 No Content" message. The timer is deleted.

[0352] If the timer with the given timer ID does not exist in the UDSF, then in step 2b, the UDSF returns a message indicating this to the NF consumer. This message may be a "404 Not Found" HTTP status code.

[0353] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a DELETE response message. Error information may be provided in the DELETE response body.

[0354] NF consumers can delete two or more autonomous timers from the relevant timer repository ( / {realmId} / {storageId} / timers) via the HTTP DELETE method. Filtering operations can be based on using metaTags in search operations for records using the "timerStatus" query parameter.

[0355] refer to Figure 20 , Figure 20 The call flow for deleting two or more autonomous timers in a UDSF is shown.

[0356] In step 1: The NF service consumer (any NF) sends a DELETE request along with a query filter to the timer resource. This defines two or more autonomous timers to be deleted.

[0357] If one or more timers meet the filtering criteria, these timers are deleted in step 2a. The UDSF can return a message to the NF consumer. This message may include an indication that the timer has been deleted. The message may include information indicating that the timer has been deleted. The message may include a 200 OK message. The message body may contain a list of URIs for timers that meet the criteria.

[0358] If no match is found, in step 2b, the UDSF will return a message indicating this to the NF consumer. This message can be a "204 No Content" message.

[0359] For failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a DELETE response message. Error information may be provided in the DELETE response body.

[0360] NF consumers can delete attached timers from the relevant resources ( / {realmId} / {storageId} / records / {recordId} / timers / {timerId}) via the HTTP DELETE method.

[0361] refer to Figure 21 , Figure 21 The call flow for deleting a single record with an attached timer in the UDSF is shown.

[0362] In step 1: The NF service consumer (any NF) sends a DELETE request to the timer resource indicated by the timer ID.

[0363] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "204 No Content" message. The timer is deleted.

[0364] If the timer for a given timer ID does not exist in the UDSF, then in step 2b, the UDSF returns a message to the NF consumer indicating this. This message may be a "404 Not Found" HTTP status code.

[0365] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a DELETE response message. Error information may be provided in the DELETE response body.

[0366] NF consumers can delete all record-attached timers belonging to a record on the relevant resource ( / {realmId} / {storageId} / records / {recordId} / timers) via the HTTP DELETE method.

[0367] refer to Figure 22 , Figure 22 The call flow for deleting all attached timers for records belonging to a record in the UDSF is shown.

[0368] In step 1: The NF service consumer (any NF) sends a DELETE request to the timer resource indicated by the record ID. This request removes all timers attached to that record.

[0369] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "204 No Content" message. All record-attached timers associated with that record are deleted.

[0370] If the record for a given record ID does not exist in the UDSF, or if the record does not have a timer, then in step 2b, the UDSF returns a message to the NF consumer indicating this. This message may be a "404 Not Found" HTTP status code.

[0371] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a DELETE response message. Error information may be provided in the DELETE response body.

[0372] NF consumers can use the HTTP GET method to search for autonomous timers in the timer repository within the record ( / {realmId} / {storageId} / timers / ). Filtering operations can be based on meta tags used in the search operation for records with the "timerStatus" query parameter, while the search operation is based on the operation used.

[0373] refer to Figure 23 , Figure 23 The call flow for autonomous timer search in UDSF is shown.

[0374] In step 1: The NF service consumer (any NF) sends a GET request to the timer repository.

[0375] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "200 OK" message. The message body may contain timers. The message body may contain a list of URIs with timers that meet the search criteria.

[0376] If the timer for a given timer ID does not exist in the UDSF, then in step 2b, the UDSF returns a message indicating this to the NF consumer. This message can be a "204 No Content" HTTP status message.

[0377] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a GET response message. Error information may be provided in the GET response body.

[0378] NF consumers can use the HTTP GET method to search for records with attached timers on the record repository. Filtering operations can be based on meta tags used in the search operation targeting the "timer status" query parameter.

[0379] refer to Figure 24 , Figure 24 The call flow for searching for record attachment timers in UDSF is shown.

[0380] In step 1: The NF service consumer (any NF) sends a GET request to the record-attached timer. In some embodiments, this can specify the timer state. This can specify a specific record.

[0381] If successful, in step 2a, the UDSF returns a success message to the NF consumer, such as a "200 OK" message. The message body may contain timers. The message body may contain a list of URIs with timers that meet the search criteria.

[0382] If a timer for a given timer ID does not exist in the UDSF, then in step 2b, the UDSF returns a message indicating this to the NF consumer. This message can be a "204 No Content" HTTP status message.

[0383] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a GET response message. Error information may be provided in the GET response body.

[0384] In some embodiments, in wildcards ( This is used when searching within a timer, allowing for the application of a search and wildcard replacement of record IDs. The call flow is as follows: Figure 25 As shown in the image. Figure 25 The calling process in the middle is as follows: Figure 24 As described, but wildcards were used.

[0385] The UDSF can notify the NF service consumer of a timer expiration. When a record expires, as indicated by the timer's expiration time attribute, the UDSF sends a notification message to the NF service consumer. This message is sent to a given callback reference.

[0386] refer to Figure 26 , Figure 26 The call flow for timer expiration notification is shown.

[0387] In step S1, UDSF sends a POST request to the callback URI. This request may contain timer details.

[0388] If successful, in step 2a, the NF consumer returns a success message to the UDSF, such as a "204 No Content" message.

[0389] If the NF service consumer does not recognize the "Callback URI" as a valid notification URI, the NF consumer sends a message to the USDF indicating this. This message may contain the HTTP status code "404 Not Found".

[0390] For any other failures, in step 2c, the NF consumer returns a failure message to the UDSF. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a POST response message. Error information may be provided in the POST response body.

[0391] NF consumers can subscribe to timer resources in a similar manner to those currently supported for recording resources. The subscription filter structure for timers can be shared with the subscription filter structure used for recording. However, this can also include, for example... Figure 27 The table shows the "EXPIRED" filter operation in the operation row.

[0392] refer to Figure 28 The table, Figure 28 These are various recording options provided by some embodiments.

[0393] “CREATED” indicates a record creation operation.

[0394] "UPDATED" indicates an update record operation.

[0395] "DELETED" indicates a record deletion operation.

[0396] “EXPIRED” indicates the expiration of a timer, such as the one discussed earlier.

[0397] refer to Figure 29 , Figure 29 An example call flow for subscribing to a timer resource is shown.

[0398] In step 1, the NF service consumer sends a PUT request to the resource indicated by the storage device ID and subscription ID. In some embodiments, the subscription may include an "EXPIRED" operation as one of the filters.

[0399] If successful, in step 2a, the UDSF returns a success message, such as a "201 Created" message, to the NF consumer. The message body may contain the notification subscription. If the expiration time is enforced due to operator policy or if the value in the request exceeds the maximum allowed expiration time, the expiration attribute of the received notification subscription may indicate a value or a value different from the requested value.

[0400] If one or more of the requested monitoring resource URIs do not exist in the UDSF, a message can be sent in step 2b to indicate this. This message can be a "409 Conflict". The message can include the non-existent monitoring resource URI.

[0401] For any other failures, in step 2c, the UDSF returns a failure message to the NF consumer. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a POST response message. Error information may be provided in the POST response body.

[0402] NF consumers can receive notifications of changes to the state or value of timer resources attached to records in a manner similar to that for record resources. Record notifications can be extended to support, for example... Figure 30 The table shows the timers. This table displays the definitions of recording notification types that support timers.

[0403] refer to Figure 31 , Figure 31 An example call flow for logging notifications for additional timers is shown.

[0404] In step 1, UDSF sends a POST request to the callback URI. This request may contain record notification details. Depending on the subscription, this may be sent when a timer is deleted, changed, or expires.

[0405] If the notification is accepted, in step 2a, the NF service consumer returns a success message to the UDSF, such as a "204 No Content" message.

[0406] For failures, in step 2b, the NF consumer returns a failure message to the UDSF. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a POST response message. Error information may be provided in the POST response body.

[0407] NF consumers can receive notifications of changes to the status or value of autonomous timer resources in a manner similar to that used for recording resources. In this case, UDSF can include a timer recording notification structure in the message body, as described above. For further details, refer to... Figure 32 The table shows the definition of the timer record notification type with the timer attributes as described above.

[0408] refer to Figure 33 , Figure 33 An example call flow for notifications used by autonomous timers is shown.

[0409] In step 1, UDSF sends a POST request to the callback URI. This request may contain timer logging notification details. Depending on the subscription, this can be sent when the timer is deleted, changed, or expires.

[0410] If the notification is accepted, in step 2a, the NF service consumer returns a success message to the UDSF, such as a "204 No Content" message.

[0411] For failures, in step 2b, the NF consumer returns a failure message to the UDSF. The failure message may include an appropriate HTTP status code indicating the error. Optionally, the failure message may include additional error information. The failure message may be a POST response message. Error information may be provided in the POST response body.

[0412] Some embodiments may be provided as additional UDSF features. UDSF consumers can discover whether a UDSF can support the functionality of certain embodiments via a supported feature negotiation mechanism, such as that specified in subclause 6.6.2 of 3GPP TS 29.500.

[0413] In some embodiments, timer operations can be an extension of the Nudsf_DataRepository service. However, in other embodiments, they can be provided by any other suitable service, such as a timer repository service, like Nudsf_timerrepository.

[0414] Some embodiments can store and manage timers, as previously described in the UDSF. It should be understood that other embodiments can be implemented in any other suitable network function. In some embodiments, the storage and management of timers can be managed by a dedicated timer function. The data storage can be configured to store UE-related data. This data can be UE state information. This data can be used in any suitable scenario.

[0415] Some implementations can support network efficiency because the consumer can be notified when the timer expires. This avoids the need for the consumer to poll for timer expiration.

[0416] Some implementations can support timer precision. In some embodiments, notification delivery can be closer to timer expiration than that achieved by periodic consumer polling.

[0417] Some implementations can support UDSF efficiency. In some embodiments, UDSF can implement an optimized timer management mechanism instead of performing multiple bulk searches (when requested by the consumer).

[0418] Some implementations can support NF simplicity. In some embodiments, NF instances in a collection can share a timer. Notifications can be sent to the NF collection regardless of which instance created the timer. When using notifications, NF instances can avoid the need to coordinate polling of timers.

[0419] Some implementations can support flexibility. Timers can be used for different purposes. UDSFs can be used to store timers without requiring a record to exist. Some implementations can support the use of two or more parallel timers associated with a single record resource.

[0420] Some embodiments can be used in any suitable scenario. For example, some embodiments can be used for NF set implementation based on a stateless NF with a backend UDSF for timer storage devices.

[0421] In some embodiments, NF can have three possible state levels.

[0422] An NF can be a stateless NF. An NF only retrieves UE state information from the UDSF during a transaction (e.g., PCF).

[0423] An NF can be a state-efficient NF. UE state information can be retrieved from the UDSF by the NF and maintained during periods of high UE activity, cached for several seconds or minutes. UE state information can also be stored in the UDSF by the NF at the end of a specific process (such as AMF or SMF).

[0424] An NF can be a stateful NF. UE state information can be permanently stored in an NF (e.g., a UDR).

[0425] In the event of an NF failure, a stateless NF or a state-efficient NF performing an NF set operation may not know the record ID of the relevant record that stores the data required to complete the operation, and may have to retrieve the data stored in the UDSF based on various search criteria. These criteria may be based on content available from requests triggered by operations or background activities (e.g., User Permanent Identifier (SUPI), Globally Unique Temporary Identifier (GSPI), timer expiration, Single Network Slice Selection Auxiliary Information (S-NSSAI), or others).

[0426] Another example is when an NF (such as an AMF) may need to run background activities to purge outdated UEs. To accomplish this, the NF may periodically need to send search queries to the UDSF to identify and retrieve records of UEs whose timers (such as reachability timers) have expired.

[0427] Some previous embodiments have been described using resource modeling formats, such as those outlined in 3GPP 29.501. A resource can represent an object that can be modified via standard HTTP methods and can be modeled with an appropriate prototype. Resource prototypes are used to help API designers construct resources. Reference prototypes can define what operations and HTTP methods a resource supports. Document prototypes are other concept library prototypes. Any resource not identified using one of the other resource prototypes is a document. This could be, for example, a timer as previously described. Collection prototypes can be used to model resources used as a resource catalog. Collections can be managed by an NF service provider, which determines the URI of each resource created in the collection. Repository prototypes can also be used to model resources used as a resource catalog, but the repository is managed by an NF service consumer. The NF service consumer decides what resources should be added to / removed from the repository. The NF service consumer determines the URI of the added resources.

[0428] However, it should be understood that this is merely exemplary and different implementations can be provided using, for example, different techniques used for resource modeling.

[0429] refer to Figure 34 , Figure 34 A method is shown. This method can be executed by a data storage device. This can be as follows: Figure 2 As described.

[0430] The method includes: in S1, storing one or more timers in one or more timer repositories, the timers being associated with data used by a stateless consumer network function or a stateful efficient consumer network function.

[0431] The method includes: in S2, monitoring the one or more timers.

[0432] The method includes, in S3, causing a notification to be sent to the consumer network function of the first timer in response to a trigger associated with a first timer of one or more timers.

[0433] refer to Figure 35 This illustrates a method. This method can be performed by a consumer-side network function or a device of a consumer-side network function. The device can be as described regarding... Figure 2 As described.

[0434] The method includes: receiving from a data repository device a notification including information about a trigger associated with a first timer, the first timer being associated with data used by a consumer network function, the consumer network function including a stateless consumer network function or a state-efficient consumer network function.

[0435] Figure 3 A schematic representation of non-volatile memory media 1900a (e.g., computer disk (CD) or digital multifunction disk (DVD)) and 1900b (e.g., Universal Serial Bus (USB) memory stick) is shown, which store instructions and / or parameters 1902, allowing the processor to execute... Figure 34 Or one or more steps of method 35.

[0436] It should be noted that although exemplary embodiments have been described above, several changes and modifications may be made to the disclosed solutions without departing from the scope of the invention.

[0437] It should be understood that although the above concepts have been discussed in the context of 5GS, one or more of these concepts can be applied to other cellular systems.

[0438] Therefore, embodiments may vary within the scope of the appended claims. Typically, some embodiments may be implemented using hardware or dedicated circuitry, software, logic, or any combination thereof. For example, some aspects may be implemented in hardware, while others may be implemented using firmware or software, which may be executed by a controller, microprocessor, or other computing device, but the embodiments are not limited thereto. While various embodiments may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it is well understood that, as non-limiting examples, implementation may take place in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices or logic, general-purpose hardware or controllers or other computing devices, or certain combinations thereof.

[0439] The embodiments can be implemented by computer software stored in memory, and can be executed by at least one data processor of the entity involved, or by hardware, or by a combination of software and hardware. Furthermore, it should be noted in this respect, for example... Figure 34 and 35 Any process within the software can represent a program step, or an interconnected logic circuit, block, or function, or a combination of program steps and logic circuits, blocks, and functions. Software can be stored on physical media such as memory chips or memory blocks implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as DVDs and their data variants, and CDs.

[0440] The memory can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. As a non-limiting example, the data processor can be of any type suitable for the local technical environment and can include one or more of general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), gate-level circuits, and processors based on multi-core processor architectures.

[0441] Alternatively or additionally, some embodiments may be implemented using circuitry. This circuitry may be configured to perform one or more of the foregoing functional and / or method steps. This circuitry may be provided in base stations and / or communication equipment.

[0442] As used in this application, the term "circuit system" may refer to one or more or all of the following:

[0443] (a) Pure hardware circuit implementation (such as implementations only in analog and / or digital circuit systems);

[0444] (b) A combination of hardware circuits and software, such as:

[0445] (i) A combination of (multiple) analog and / or digital hardware circuits with software / firmware, and

[0446] (ii) Any part of (multiple) hardware processors, together with software (including (multiple) digital signal processors), software, and (multiple) memories, work together to enable a device (such as a mobile phone or server) to perform various functions; and

[0447] (c) (Multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or a portion thereof, which require software (e.g., firmware) to operate, but may not exist when operation does not require the software.

[0448] This definition of circuit system applies to all uses of the term in this application, including in any claim. As another example, as used in this application, the term circuit system also covers implementations of hardware circuitry or a processor (or processors), or a portion of hardware circuitry or a processor and / or its accompanying software and / or firmware. The term circuit system also covers, for example, integrated devices.

[0449] The foregoing description has provided a complete and informative description of some embodiments by way of exemplary and non-limiting examples. However, various modifications and adaptations will be apparent to those skilled in the art from the foregoing description when read in conjunction with the accompanying drawings and the appended claims. Nevertheless, all such and similar modifications taught will still fall within the scope defined by the appended claims.

Claims

1. An apparatus for a communication network, the apparatus comprising: Unstructured data storage function UDSF is configured for: In one or more record repositories, timers associated with one or more records are stored, the timers associated with one or more records being associated with one or more records, and the one or more record repositories being directly under the region and storage device of the Resource Uniform Resource Identifier URI of the UDSF Application Programming Interface API; One or more autonomous timers are stored in one or more timer repositories, the one or more autonomous timers being unassociated with the one or more records, the one or more timer repositories being directly under the region and the storage device of the resource uniform resource identifier URI; Monitor the one or more autonomous timers; and In response to a trigger associated with a first autonomous timer among the one or more autonomous timers, a notification associated with the first autonomous timer is sent via the API to the network function consumer of the first autonomous timer.

2. The apparatus of claim 1, wherein the UDSF is configured to store status information for one or more communication devices, the status information being used by the network function consumer of the first autonomous timer.

3. The apparatus of claim 1 or 2, wherein the triggering includes one of the following: expiration of the first autonomous timer; change of the first autonomous timer; and deletion of the first autonomous timer.

4. The apparatus of claim 1 or 2, wherein the UDSF is further configured to store subscriptions for the first autonomous timer, the subscriptions indicating the triggering associated with the first autonomous timer.

5. The apparatus of claim 1 or 2, wherein the UDSF is configured to store a callback reference for the first autonomous timer, the callback reference indicating a Uniform Resource Locator to which the notification is to be sent via the API.

6. The apparatus of claim 1 or 2, wherein the UDSF is configured to delete a timer associated with one or more records associated with the one record when the record is deleted.

7. The apparatus of claim 6, wherein the UDSF is configured to, in response to receiving a request from the network function consumer for creating, modifying, or deleting one of the timers associated with the one or more records, create, modify, or delete a timer associated with one of the one or more records, the request including the identity of the one of the one or more records.

8. The apparatus of claim 1 or 2, wherein the UDSF is configured to receive from the network function consumer a search request for information about timers associated with the one or more records or the one or more autonomous timers, perform a search according to the search request to provide search results, the search results including information about timers associated with the one or more records or the one or more autonomous timers, and be configured to provide a response to the search request, the response including the search results.

9. The apparatus of claim 8, wherein the search request includes a filter, and the search result includes information about a timer or one or more autonomous timers associated with one or more records that satisfy the filter, the filter including one or more of timer status and metadata tags.

10. A method performed by the Unstructured Data Storage Function (UDSF) of a communication network, the method comprising: In one or more record repositories, timers associated with one or more records are stored, the timers associated with one or more records being associated with one or more records, and the one or more record repositories being directly under the region and storage device of the Resource Uniform Resource Identifier URI of the UDSF Application Programming Interface API; One or more autonomous timers are stored in one or more timer repositories, the one or more autonomous timers being unassociated with the one or more records, the one or more timer repositories being directly under the region and the storage device of the resource uniform resource identifier URI; Monitor the one or more autonomous timers; and In response to a trigger associated with a first autonomous timer among the one or more autonomous timers, a notification associated with the first autonomous timer is sent via the API to the network function consumer of the first autonomous timer.

11. The method of claim 10, comprising: The status information for one or more communication devices is stored, and the status information is used by the network function consumer of the first autonomous timer.

12. The method of claim 10 or 11, wherein the triggering includes one of: the expiration of the first autonomous timer; the change of the first autonomous timer; and the deletion of the first autonomous timer.

13. The method according to claim 10 or 11, comprising: Store a subscription for the first autonomous timer, the subscription indicating the trigger associated with the first autonomous timer.

14. The method according to claim 10 or 11, comprising: Store a callback reference for the first autonomous timer, the callback reference indicating the Uniform Resource Locator to which the notification is to be sent via the API.

15. The method according to claim 10 or 11, comprising: When one of the records is deleted, the timers associated with the one or more records associated with that record are also deleted.

16. The method of claim 15, comprising: In response to receiving a request from the network function consumer for the creation, modification, or deletion of one of the timers associated with the one or more records, the timer associated with the one or more records is created, modified, or deleted, the request including the identity of the one or more records.

17. The method according to claim 10 or 11, comprising: The network function consumer receives a search request for information about timers associated with the one or more records or the one or more autonomous timers, performs a search based on the search request to provide search results, the search results including information about timers associated with the one or more records or the one or more autonomous timers, and provides a response to the search request, the response including the search results.

18. The method of claim 17, wherein the search request includes a filter, and the search results include information about timers or autonomous timers associated with one or more records that satisfy the filter, the filter including one or more of timer states and metadata tags.

19. A computer program product comprising computer-executable code, wherein the computer-executable code, when executed on a computing device, causes the computing device to: In one or more record repositories, timers associated with one or more records are stored, the timers associated with one or more records being associated with one or more records, the one or more record repositories being directly under the region and storage device of the Resource Uniform Resource Identifier URI of the Application Programming Interface API of the Unstructured Data Storage Function (UDSF); One or more autonomous timers are stored in one or more timer repositories, the one or more autonomous timers being unassociated with the one or more records, the one or more timer repositories being directly under the region and the storage device of the resource uniform resource identifier URI; Monitor the one or more autonomous timers; and In response to a trigger associated with a first autonomous timer among the one or more autonomous timers, a notification associated with the first autonomous timer is sent via the API to the network function consumer of the first autonomous timer.

20. The computer program product of claim 19, comprising computer-executable code, wherein when the computer-executable code is executed on the computing device, the computing device causes the computing device to: The status information for one or more communication devices is stored, and the status information is used by the network function consumer of the first autonomous timer.

21. The computer program product of claim 19 or 20, wherein the trigger includes one of the following: expiration of the first autonomous timer; change of the first autonomous timer; and deletion of the first autonomous timer.

22. The computer program product of claim 19 or 20, comprising computer-executable code, which, when executed on the computing device, causes the computing device to: Store a subscription for the first autonomous timer, the subscription indicating the trigger associated with the first autonomous timer.

23. The computer program product of claim 19 or 20, comprising computer-executable code, which, when executed on the computing device, causes the computing device to: Store a callback reference for the first autonomous timer, the callback reference indicating the Uniform Resource Locator to which the notification is to be sent via the API.

24. The computer program product of claim 19 or 20, comprising computer-executable code, which, when executed on the computing device, causes the computing device to: When one of the records is deleted, the timers associated with the one or more records associated with that record are also deleted.

25. The computer program product of claim 24, comprising computer-executable code, wherein when the computer-executable code is executed on the computing device, the computing device causes the computing device to: In response to receiving a request from the network function consumer for the creation, modification, or deletion of one of the timers associated with the one or more records, the timer associated with the one or more records is created, modified, or deleted, the request including the identity of the one or more records.

26. The computer program product of claim 19 or 20, comprising computer-executable code, which, when executed on the computing device, causes the computing device to: The network function consumer receives a search request for information about timers associated with the one or more records or the one or more autonomous timers, performs a search based on the search request to provide search results, the search results including information about timers associated with the one or more records or the one or more autonomous timers, and provides a response to the search request, the response including the search results.

27. The computer program product of claim 26, wherein the search request includes a filter, and the search results include information about timers or the one or more autonomous timers associated with one or more records that satisfy the filter, the filter including one or more of timer status and metadata tags.

Images