Method and system for pushing notification message in SEAL notification management service

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Methods and systems for handling push notification messages in a service enabler architecture layer notification management (SNM) service are disclosed. A method may be used for an advanced process using a hypertext transfer protocol (HTTP) to enable an SNM server (SNM-S) to push notification messages to an SNM client (SNM-C).

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to a notification method and system, and more particularly, to a method and system for processing a push notification message in a service enabler architecture layer (SEAL) notification management service. BACKGROUND

[0002] 5G mobile communication technologies define wide frequency bands so that high transmission rates and new services are possible, and are implemented not only in "Sub 6 GHz" bands but also in "Above 6 GHz" bands (mmWave). Furthermore, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in Terahertz bands (for example, 95 GHz to 3 THz bands) in order to accomplish transmission rates higher than 5G mobile communication technologies and ultra-low latencies of about 100 times lower than 5G mobile communication technologies.

[0003] At the time when the development of 5G mobile communication technologies is in progress, there are ongoing standardization efforts regarding, in order to support services and meet requirements related to Enhanced Mobile Broadband (eMBB) that is a wide range of speed of about 20 Gbps, Ultra Reliable Low Latency Communications (URLLC) that is a low latency of about 0.5 ms and massive Machine Type Communications (mMTC) that is a very large number of access devices of about 1,000,000 per km2, beamforming and massive MIMO that are techniques for mitigating radio wave path loss and increasing radio wave transmission distances in mmWave of 60 GHz, support of initial access technologies for supporting multi-beam transmission and wideband, definition and operation of BWP (Bandwidth Part) for supporting the above-described techniques, new channel coding methods such as a LDPC (Low Density Parity Check) code for large amounts of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network for a specific service.

[0004] At present, in view of services to be supported by 5G mobile communication technologies, there are ongoing discussions regarding improvements and performance enhancements of initial 5G mobile communication technologies, and there are ongoing standardization efforts regarding physical layer technologies such as V2X (Vehicle-to-Everything) for determining a driving of an autonomous vehicle based on information about a position and a state of a vehicle transmitted by the vehicle and for enhancing user convenience, NR-U (New Radio Unlicensed) for system operations conforming to various regulatory requirements within unlicensed bands, NR UE power saving, Non-Terrestrial Network (NTN) for providing coverage in an area where ground communication is not available as a direct communication between a UE and a satellite, and positioning.

[0005] Further, in the field of air interface architecture / protocol, standardization is ongoing regarding technologies such as Industrial Internet of Things (IIoT) for support of new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access (two-step RACH for NR) for simplifying a random access procedure. In the field of system architecture / service, standardization is also ongoing regarding 5G baseline architecture (e.g., service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and mobile edge computing (MEC) for receiving services based on UE location.

[0006] As 5G mobile communication systems are commercialized, connected devices, which have increased exponentially, will be connected to communication networks, and thus it is expected that enhanced functionality and performance of 5G mobile communication systems and integrated operation of connected devices will be necessary. For this reason, new research is scheduled, involving extended reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality), etc., 5G performance improvement and complexity reduction by utilizing artificial intelligence (AI) and machine learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Further, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage of terahertz bands for 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas, lenses and antennas based on metamaterials for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for improving frequency efficiency of 6G mobile communication technologies and ameliorating system networks, AI-based communication technology for system optimization from the design stage by utilizing satellites and AI (Artificial Intelligence) and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at a level of complexity exceeding the limit of UE operation capability by utilizing super-high-performance communication and computing resources.

[0008] Currently, each application (e.g., chat, social media, or financial application) on a user equipment (UE) (e.g., a smartphone or a laptop) listens to notification messages from their respective servers, known as vertical application layer (VAL) servers. This generates excessive traffic on the network, as each VAL server is deployed in different regions running on different internet protocol (IP) addresses and ports. Due to continuous listening to notifications from the UE, the UE consumes excessive computing resources and power. SUMMARY

[0009] SOLUTION TO THE PROBLEM

[0010] The present disclosure has been made to solve at least the above-mentioned problems and / or disadvantages and to provide at least the advantages described below.

[0011] Accordingly, an aspect of the present disclosure is to provide a method and system for handling push notification messages in a SEAL notification management service.

[0012] An aspect of the present disclosure is to provide a high-level procedure using hypertext transfer protocol (HTTP) to enable the SNM-S to push notification messages to the SNM-C.

[0013] An aspect of the present disclosure is to provide a procedure for the SNM-C to receive notification messages from the SNM-S over a notification channel and to decode the received notification messages.

[0014] An aspect of the present disclosure is to provide a procedure for the SNM-S to encode notification messages and push these notification messages to the SNM-C over a notification channel.

[0015] An aspect of the present disclosure is to provide a message format for encoding notification messages to be pushed by the SNM-S to the SNM-C.

[0016] An aspect of the present disclosure is to provide a generic notification payload format that will store messages received by different VAL servers, where the messages are different in each notification as they are received from different VAL servers.

[0017] An aspect of the present disclosure is to provide a method and apparatus for encoding and decoding these notification payloads and notification message formats in the SNM service.

[0018] An aspect of the present disclosure is to enable the SNM-C to share a push callback-URL (PUSH callback-URL) as part of the create notification channel procedure.

[0019] One aspect of this disclosure is enabling the SNM-S to manage and use push callback URLs to push future notification messages from the SNM-S to the SNM-C upon successful creation.

[0020] According to one aspect of this disclosure, a method for managing push notification messages in a SEAL Notification Management (SNM) service includes: an SNM client (SNM-C) receiving an HTTP POST request from an SNM server (SNM-S) via a push callback URI; the SNM-C matching an identifier (ID) received in a channel ID parameter associated with the HTTP POST request with a channel ID stored locally at the SNM-C; after matching the ID received in the channel ID parameter associated with the HTTP POST request with a channel ID stored locally at the SNM-C, the SNM-C sending an HTTP response to the SNM-S; the SNM-C processing a VAL notification message list parameter including at least one encoded VAL notification message received in the HTTP request entity body of the HTTP POST request; and the SNM-C delivering the push notification message received from the VAL notification message list parameter to a VAL client running on a UE.

[0021] According to one aspect of this disclosure, a method for managing push notification messages in an SNM service includes: receiving push notification messages from a VAL server by an SNM server (SNM-S); determining that a push notification channel exists with an SNM-C to receive push notification messages matching a VAL ID shared by the VAL server; generating an HTTP POST message by the SNM-S, wherein the HTTP body is set with a VAL notification message payload, the VAL notification message payload storing each push notification message encoded in the form of a VAL notification message received from the VAL server; and sending the generated HTTP POST message to the SNM-C by the SNM-S.

[0022] According to one aspect of this disclosure, the SNM-C includes a processor, a memory, and a push notification message processing controller coupled to the processor and the memory. The push notification message processing controller is configured to receive an HTTP POST request from the SNM-S via a push callback URI, match an ID received in a channel ID parameter associated with the HTTP POST request with a channel ID stored locally at the SNM-C, send an HTTP response to the SNM-S after matching the ID received in the channel ID parameter associated with the HTTP POST request with a channel ID stored locally at the SNM-C, process a VAL notification message list parameter, including decoding at least one encoded VAL notification message received in the HTTP request entity body of the HTTP POST request, and delivering each push notification message received from the VAL notification message list parameter to a VAL client running on the UE.

[0023] According to one aspect of this disclosure, the SNM-S includes a processor, a memory, and a push notification message processing controller coupled to the processor and the memory. The push notification message processing controller is configured to receive push notification messages from a VAL server, determine the existence of a push notification channel with a SEAL notification management client (SNM-C), receive push notification messages that match a VAL ID shared by the VAL server, generate an HTTP POST message with an HTTP body containing a VAL notification message payload, the VAL notification message payload storing a push notification message encoded in VAL notification message form received from the VAL server, and send the generated HTTP POST request to the SNM-C.

[0024] According to one aspect of this disclosure, a method for managing and sharing push callback URLs in a SEAL notification management (SNM) service includes: an SNM client (SNM-C) receiving a request from a VAL service for receiving push notification messages via a notification channel; the SNM-C sending an HTTP POST request to an SNM server (SNM-S) based on the request received from the VAL service; the SNM-C creating a push notification channel and an associated push callback URI based on the HTTP POST request; upon receiving an HTTP 200 OK response message from the SNM-S, the SNM-C notifying the VAL service of the successful reception of the push notification message via the notification channel; and the SNM-C listening for push callback URIs to receive future push notification messages from the SNM-S.

[0025] According to one aspect of this disclosure, a method for managing and sharing push notification messages in a SEAL Notification Management (SNM) service includes: receiving an HTTP POST request for creating a notification channel request from an SNM client (SNM-C) by an SNM server (SNM-S), wherein the request URL associated with the HTTP POST request includes the URL of SNM-S; processing the creation notification channel request by SNM-S when it is determined that the channel type is push type and the requester identifier of the received HTTP POST request is an authorized requester; processing push channel details by SNM-S to obtain the push callback URL of SNM-C when it is determined that the channel type is push type; creating a notification channel response message indicating successful creation of the notification channel by SNM-S; sending an HTTP 200 OK response message including the notification channel response message to SNM-C by SNM-S; and storing the push callback URL processed by SNM-C for future use when the notification message is pushed to SNM-C, wherein the notification message is addressed to the push callback URI of SNM-C.

[0026] According to one aspect of this disclosure, a SEAL notification management server (SNM-S) includes a processor, a memory, and a push notification message processing controller coupled to the processor and the memory. The push notification message processing controller is configured to receive an HTTP POST request from a SEAL notification management client (SNM-C) for creating a notification channel, wherein the request URL associated with the HTTP POST request includes the URL of SNM-S; process the create notification channel request when it is determined that the channel type is push and the requester identifier of the received HTTP POST request is an authorized requester; process push channel details when it is determined that the channel type is push to obtain the push callback URI of SNM-C; create a notification channel response message indicating successful creation of the notification channel; send an HTTP 200 OK response message including the notification channel response message to SNM-C; and store the push callback URL processed by SNM-C by SNM-S for future use when a notification message is pushed to SNM-C, wherein the notification message is addressed to the push callback URI of SNM-C. Attached Figure Description

[0027] The foregoing and other aspects, features, and advantages of the embodiments herein will become more apparent from the following description with reference to the accompanying drawings, in which:

[0028] Figure 1 A system for managing push notification messages in a SEAL notification management service, according to an embodiment, is shown;

[0029] Figure 2A system for managing push callback URLs in an SNM service, according to an embodiment, is shown;

[0030] Figure 3 The hardware components of SNM-C according to an embodiment are shown;

[0031] Figure 4 The hardware components of the SNM-S according to an embodiment are shown;

[0032] Figure 5 A method for managing push notification messages in a SEAL notification management service, implemented using SNM-C according to an embodiment, is shown.

[0033] Figure 6 A method for managing push notification messages in a SEAL notification management service, implemented by SNM-S according to an embodiment, is shown.

[0034] Figure 7 A method for managing push callback URL notification messages in the SEAL notification management service during a notification channel creation procedure invocation, implemented by SNM-C according to an embodiment, is shown.

[0035] Figure 8 A method for managing push callback URLs in the SEAL notification management service during a notification channel creation procedure call, implemented by SNM-S according to an embodiment, is shown. Detailed Implementation

[0036] The following description, provided with reference to the accompanying drawings, is intended to aid in a comprehensive understanding of embodiments of the present disclosure. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. For clarity and brevity, descriptions of well-known functions and structures may be omitted.

[0037] In this document, the term "exemplary" is used to indicate "serving as an example, instance, or illustration." Embodiments or implementations of the subject matter described herein as "exemplary" are not necessarily to be construed as preferred or advantageous over other embodiments.

[0038] While this disclosure is applicable to various modifications and alternatives, embodiments thereof have been illustrated by way of example in the accompanying drawings and will be described in detail below. However, it should be understood that this disclosure is not intended to be limited to the specific forms disclosed, but rather, this disclosure will cover all modifications, equivalents, and alternatives falling within the scope of this disclosure.

[0039] The term "comprising" or similar terms are intended to cover non-exclusive inclusion, such that an arrangement, device, or method that includes a list of components or steps includes not only those components or steps but may also include other components or steps not expressly listed or inherent to such arrangement, device, or method. Without further constraints, one or more elements in an apparatus or system that are followed by "comprising...one" do not exclude the presence of other elements or additional elements in that apparatus or system.

[0040] In the following detailed description, reference is made to the accompanying drawings, which illustrate embodiments of the present disclosure that may be practiced. These embodiments have been described in sufficient detail to enable those skilled in the art to practice the present disclosure, and it should be understood that other embodiments may be utilized and changes may be made without departing from the scope of the present disclosure. Therefore, the following description should not be considered limiting.

[0041] Definitions (as defined herein) will apply, and where appropriate, terms used in the singular will also include the plural, and vice versa.

[0042] The terminology used herein is for the purpose of describing particular embodiments only and is not restrictive. Unless otherwise stated, the terms “comprising,” “having,” and “including” should be interpreted as open-ended terms.

[0043] The words / phrases “example,” “illustration,” “in an instance,” “etc.,” “for example,” and “i.e.” are used herein only to indicate “serving as an example, instance, or illustration.” Any embodiment or implementation of the subject matter described herein using the words / phrases “example,” “illustration,” “in an instance,” “etc.,” “for example,” and “i.e.” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0044] The elements in the accompanying drawings are shown for purposes of description and ease of understanding and may not necessarily be drawn to scale. For example, flowcharts / sequence diagrams illustrate methods according to the steps required to understand aspects of the embodiments disclosed herein. Depending on the construction of the device, one or more components of the device may have been represented by conventional symbols in the drawings, and the drawings may only show those specific details relevant to understanding the embodiments, so as not to obscure the drawings with details that would be readily apparent to those skilled in the art who would benefit from the description herein. Depending on the system, one or more components / modules comprising the system may have been represented by conventional symbols in the accompanying drawings, and the drawings may only show those specific details relevant to understanding the embodiments, so as not to obscure the drawings with details that would be readily apparent to those skilled in the art who would benefit from the description herein.

[0045] The accompanying drawings are provided to aid in the easy understanding of the various technical features, and the embodiments presented herein are not limited to the drawings. Therefore, this disclosure should be construed as extending to any modifications, equivalents, and substitutions other than those specifically set forth in the drawings and corresponding descriptions. The use of terms such as first, second, third, etc., to describe components / elements / steps is for the purposes of this description and should not be construed as a sequential order / placement / occurrence unless otherwise stated.

[0046] In the SEAL Notification Management Service, the 3GPP Technical Specification (TS) 24.542 defines the notification mechanism to be consumed by applications running in the UE. The SEAL Notification Management Client (SNM-C) sends a request to the SEAL Notification Management Server (SNM-S) to create a notification channel. When the process is successful, the SNM-S sends a response with a callback associated with the SNM-S.

[0047] Currently, the specification defines the procedure for providing a callback associated with the SNM-S to the notification channel when the SNM-C creates a notification channel with the SNM-S. Applications residing in the UE can use the notification channel by sharing the callback associated with the SNM-S to their VAL server for pushing future notification messages via the SNM-S. Therefore, SEAL notification management offloads the responsibility of notification management performed by each application residing on the UE and achieves this functionality through a simplified approach using only one or a few notification channels between the SNM-C and SNM-S.

[0048] However, if SNM-S needs to push notification messages to SNM-C via the activity notification channel, the specification for notification management does not define any push message procedure. Therefore, whenever a new user is added to a messaging group or an existing user is removed from a messaging group on the SEAL group server, or when the location server wants to notify the UE of changes in location information, applications residing on UEs registered with SNM-C will not receive any notifications from SNM-S, as SNM-S has already received the messages from its VAL server.

[0049] The above are just two examples, but this example can be applied to any real-time notification.

[0050] Furthermore, 3GPP TS 24.542 for NM prevents SNM-C from exposing push callback Uniform Resource Locators (URLs) as part of the notification channel creation process. However, while SNM-C creates and maintains an active notification channel with SNM-S, SNM-S cannot push any notification messages to SNM-C because SNM-C has not yet provided its listening URL for receiving notification messages pushed from SNM-S. This defeats the primary purpose of creating a push notification channel.

[0051] Therefore, there is a need in the art for methods and systems that can process push notification messages in the SEAL notification management service.

[0052] In 3GPP TS 24.542, there is currently no procedure defined for pushing notification messages addressed to SNM-C for SNM-S. Therefore, this disclosure provides a new high-level procedure using the HTTP protocol with the proposed notification message payload, which enables SNM-S to push notification messages to SNM-C. The method and system can be used to process push notification messages in the SEAL notification management service.

[0053] The methods disclosed herein can be used to push notification messages in wireless or wired networks. A new "expandable" information element is disclosed to represent NM payloads embedded in a list of NMs. A new "encoding scheme" is disclosed and included in the content type header field of the HTTP request, as defined in "application / vnd.3gpp.seal-notification-payload / json".

[0054] The open push notification process allows SNM-S to easily push notification messages to SNM-C without excessive resource usage.

[0055] Figure 1 A system (100) for managing push notification messages in a SEAL notification management service, according to an embodiment, is shown.

[0056] In step 101, SNM-S (140) receives notification messages from VAL server (150) to share with VAL client (120). In step 102, SNM-S (140) encodes the VAL notification messages received from VAL server (150) to prepare a VAL notification message list. In step 103, SNM-S (140) sends an HTTP POST with the VAL notification message list to SNM-C (130). In step 104, after receiving the HTTP POST with the VAL notification message list from SNM-S (140), SNM-C (130) sends a response to the HTTP POST request to SNM-S (140). In step 105, SNM-C (130) decodes the VAL notification messages in the received VAL notification message list. In step 106, SNM-C (130) shares NM with VAL client (120).

[0057] A method is disclosed for an SNM-S (140) to encode an NM payload, the NM payload comprising a list of notification messages sent to an SNM-C (130) in an HTTP request body. A method is also disclosed for an SNM-C (130) to decode an NM payload, the NM payload comprising a list of notification messages received from an SNM-S (140) in an HTTP request body.

[0058] The following describes the various procedures used to manage push notification messages in the SEAL Notification Management Service.

[0059] NM delivery

[0060] The process of receiving push notification messages: When an HTTP POST request is received via the push callback URL or push callback Uniform Resource Identifier (URI) given to SNM-S (140) when the notification channel is created, SNM-C (130) will:

[0061] a) The ID received in the channel ID parameter of the HTTP POST request will be matched against the locally stored channel ID. If the channel IDs do not match, then:

[0062] a. Send an HTTP 406 (Unacceptable) response to SNM-S (140) and ignore the remaining steps (e.g., skip the remaining steps);

[0063] b) Send an HTTP 200 (OK) response to SNM-S (140); and

[0064] c) Process the list of VAL notification messages received in the HTTP request entity body as specified in Table 1 below, and deliver each received notification message to the appropriate VAL client (120) on the UE (110) that matches the VAL_ID cluster information parameter received with each message.

[0065] The process of sending push notification messages: In order to send the push notification message received from the VAL server (150) to SNM-C (130), SNM-S (140):

[0066] a) Determine whether the SNM-C (130) has a push notification channel to receive an NM that matches the VAL identifier (e.g., VAL UE or VAL user ID, VAL service ID, VAL application ID, etc.) shared by the VAL server (150). If no channel is created, ignore the remaining steps.

[0067] b) Generate an HTTP POST message to send the notification message received from the VAL server (150). In the HTTP POST message:

[0068] 1) Set the request URI to the push callback URI or push callback URL received when the channel is created;

[0069] 2) Set the Content-Type header to "application / vnd.3gpp.seal-notification-payload / json";

[0070] 3) Generate the NM effective payload as specified in Table 1 below:

[0071] i) Set the channel ID associated with SNM-C (130);

[0072] ii) Generate an NM list for messages received from the VAL server (150), as specified in Table 2 below; and

[0073] 4) Includes an HTTP request entity body having the parameters specified in Table 1 below, serialized into a JavaScript ObjectNotation (JSON) structure as specified in Internet Engineering Task Force Request Note (IETF RFC) 7159; and

[0074] c) Send an HTTP POST request to SNM-C(130).

[0075] The information in Tables 1, 2 and 3 below provides a specification description of the parameters that will be sent from SNM-S (140) to SNM-C (130) when sending notification messages via the notification channel.

[0076] Server-side parameters: SNM-S (140) transmits the following parameters from Tables 1, 2, and 3 simultaneously with sending NM via the notification channel.

[0077] Table 1

[0078] Table 1: Server-side parameters used for notification message payload

[0079]

[0080] Table 2

[0081] Table 2: VAL Notification Messages

[0082]

[0083] Table 3

[0084] Table 3: VAL Identifier Cluster Information

[0085]

[0086] Figure 2 A system (200) for managing push callback URLs in an SNM service, according to an embodiment, is shown.

[0087] This disclosure provides a method for enabling SNM-C (130) to share a push callback URL for establishing a push notification channel with SNM-S (140), provides an extensible information element representing push channel details and the push callback URL, provides a method for SNM-C (130) to encode the push callback URL and embed it under push channel detail parameters sent as part of a create notification channel request sent to SNM-S (140), and provides a method for SNM-S (140) to decode the push callback URL in push channel detail parameters received from SNM-C (130) as part of the create notification channel request body.

[0088] refer to Figure 2 In step 201, SNM-C (130) sends an HTTP POST request containing notification channel creation information and a push callback URL to SNM-S (140). In step 202, SNM-S (140) processes the notification channel information received along with the push callback URL. In step 203, SNM-S (140) stores the push callback URL for future NM pushes to SNM-C (130). In step 204, SNM-S (140) generates a response to SNM-C (130) for push notification channel creation with the SNM-S callback URL (see Table 7 below). In step 205, SNM-S (140) sends a response to the HTTP POST request for creating the notification channel to SNM-C (130). In step 206, SNM-C (130) decodes the notification channel creation response from SNM-S (140) and selects the SNM-S callback URL. In step 207, SNM-C (130) shares the SNM-S callback URL with the VAL client (120). In step 208, the VAL client (120) shares the SNM-S callback URL with the VAL server (150) to receive future notifications via the push notification channel through SNM-S (140).

[0089] Notification channel creation process:

[0090] SNM Client Procedure: Upon receiving a request to receive a notification via the notification channel from the VAL service, SNM-C (130) can create a notification channel by sending an HTTP POST request to SNM-S (140). In the HTTP POST request, SNM-C (130):

[0091] a) Set the request URI to the URI of SNM-S (140);

[0092] b) Includes a host header with a public user identifier having SNM-S (140);

[0093] c) Includes an authorization header field in which the “bearer” authentication scheme is set to an access token of type “bearer” as specified in IETF RFC 6750;

[0094] d) Includes the Content-Type header field set to "application / vnd.3gpp.seal-create-notification-channel-request";

[0095] e) Generate a notification channel creation request message, as specified in Table 4 below:

[0096] 1) Set the requester identifier to the notification management client identifier;

[0097] 2) For VAL applications that use notification channels based on requests, set the channel type to pull (PULL) or push (PUSH).

[0098] 3) If the channel type is PUSH, set the PUSH channel details parameters with the push callback URL; and

[0099] 4) Set the effective duration of the notification channel;

[0100] 5) Set the VAL ID cluster list parameter, which contains a list of VAL identifiers corresponding to each VAL service that requests to receive notifications via the notification channel; and

[0101] f) Includes the parameters specified in Table 4 below, as in the JSON structure defined in IETF RFC 7159.

[0102] Upon receiving HTTP 200 (OK), SNM-C (130) notifies the VAL service of the successful creation of the notification channel and listens for the push callback URL to receive the push NM from SNM-S (140).

[0103] SNM server procedure: Upon receiving an HTTP POST request from SNM-C (130), where the request-URI of the HTTP POST request contains the URI of SNM-S (140), SNM-S (140):

[0104] a) Determine the requester identifier of the received HTTP POST request as specified in

[0057] , and:

[0105] 1) If the sender of the received HTTP POST request is not an authorized user, respond to the HTTP POST request with an HTTP 403 (Forbidden) response and ignore the remaining steps;

[0106] b) Process the request to create a notification channel, and if the channel type is:

[0107] 1) Push notification, SNM-S (140) processing:

[0108] i) Push channel details parameters, used to obtain the push callback URL of SNM-C (130);

[0109] A) If no push callback URL is provided, the SNM-S (140) application responds to the HTTP POST request with an HTTP 406 (unacceptable) response and ignores the remaining steps;

[0110] B) When NM is to be pushed to SNM-C (130), SNM-S (140) stores this push callback URL for future use.

[0111] ii) The VAL ID cluster list parameter is a list of VAL identifiers corresponding to each VAL service that requests to receive notification messages via the notification channel.

[0112] 2) Pull, SNM-S (140) waits for SNM-C (130) to pull NM;

[0113] c) Validity duration sharing is handled by SNM-C (130).

[0114] Note: SNM-S (140) stores information about authorized users and information shared as part of the request to create a notification channel for future reference.

[0115] Upon successful creation of the notification channel; SGM-S:

[0116] a) Create a notification channel response message with the following attributes as specified in Table 7 (refer to 3GPP TS24.542).

[0117] 1) Generate a unique channel ID;

[0118] 2) Generate a callback URL (e.g., an SNM-S callback URL), which should be used by the VAL client in the UE to share it with the VAL server as part of its corresponding service;

[0119] 3) The effective duration of the generated notification channel;

[0120] 4) Generate a notification URL. In the case of the pull channel type, SNM-C (130) will use the notification URL to pull notifications from SNM-S (140);

[0121] b) Includes the Content-Type header field set to "application / vnd.3gpp.seal-create-notification-channel-response"; and

[0122] c) Send an HTTP 200 (OK) response that includes the message generated above.

[0123] Client-side parameters: SNM-C (130) transmits the following parameters when sending the request to create a notification channel. Table 4 below shows the client-side parameters used for the request to create a notification channel.

[0124] Table 4

[0125] Table 4: Client-side parameters

[0126]

[0127] Table 5

[0128] Table 5: Push Channel Details

[0129]

[0130] Table 6

[0131] Table 6: VAL_ID Cluster Information

[0132]

[0133] Table 7

[0134] Table 7: Push Notification Channel Creation

[0135]

[0136] Figure 3 The hardware components of an SNM-C (130) according to an embodiment are shown. Reference Figure 3 The SNM-C (130) includes a processor (210), a communicator (220), a memory (230), and a push NM processing controller (240). The processor (210) is coupled to the communicator (220), the memory (230), and the push NM processing controller (240).

[0137] When the push NM processing controller (240) receives an HTTP POST request from the SNM-S (140) via the push callback URL, it matches the ID received in the channel ID parameter associated with the HTTP POST request with the channel ID stored locally at the SNM-C (130). The push callback URL is shared with the SNM-S (140) when the notification channel is created.

[0138] After matching the ID received in the channel ID parameter associated with the HTTP POST request with the channel ID stored locally at SNM-C (130), the NM processing controller (240) is pushed to send an HTTP response to SNM-S (140).

[0139] The push NM processing controller (240) processes the VAL NM list parameter, which includes the encoded VAL NM received in the HTTP request entity of an HTTP POST request. The VAL NM list parameter includes a channel ID and at least one from the VAL NM list. The channel ID is the ID of the notification channel corresponding to SNM-C (130). The VAL NM list includes a list of NMs. Each NM from the list of NMs represents a message received from the VAL server (150) and encoded by SNM-S (140).

[0140] The push NM processing controller (240) delivers each push NM received from the VAL NM list parameters to the corresponding VAL client (120) running on the UE (110). The decoded form of the push NM is delivered to the VAL client (120) running on the UE (110), whose VAL identifier matches the VAL ID cluster information parameter associated with the push NM.

[0141] As part of the SEAL notification management service, push NMs are managed during the push notification channel process. A push NM includes at least one of the following: VAL ID cluster information, VAL NM type, VAL NM length, and VAL NM. The VAL ID cluster information includes the VAL ID shared by the VAL servers (150) and the VAL NM, and is modified by the SNM-S (140). The VAL NM type includes the content type of the VAL NM shared by the VAL servers (150). The VAL NM length includes the length of the VAL NM. The VAL NM includes the message received from the VAL server (150) to be notified to the VAL client (120) via the SEAL notification channel.

[0142] The push NM processing controller (240) sends an appropriate HTTP response in response to determining whether a matching channel ID has been found.

[0143] After receiving a request from the VAL service to receive a push NM via a notification channel, the push NM processing controller (240) sends an HTTP POST request to the SNM-S (140). The push NM processing controller (240) sends an HTTP POST request to the SNM-S (140) to create a push notification channel and an associated push callback URL. Upon receiving an HTTP 200 OK message from the SNM-S (140), the push NM processing controller (240) notifies the VAL service of a successful receipt of the push NM via the notification channel. The push NM processing controller (240) listens for the push callback URL to receive future push NMs from the SNM-S (140).

[0144] The push NM processing controller (240) generates a notification channel request message. This is achieved by setting the requester identifier to the notification management client identifier, setting the channel type to pull or push based on the VAL application requesting the notification channel, setting the push channel details parameter with a push callback URL if the channel type is push, setting the effective duration of the notification channel, and setting a VAL ID cluster list parameter containing a list of VAL identifiers corresponding to each VAL service requesting to receive notifications via the notification channel.

[0145] The push NM processing controller (240) is implemented by analog and / or digital circuitry, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuitry, etc., and may optionally be driven by firmware.

[0146] The processor (210) may include one or more processors. The one or more processors may be general-purpose processors (such as central processing unit (CPU), application processor (AP), etc.), graphics-only processing units (such as graphics processing unit (GPU), vision processing unit (VPU)) and / or AI-specific processors (such as neural processing unit (NPU)). The processor (210) may include multiple cores and is configured to execute instructions stored in memory (230).

[0147] The processor (210) is configured to execute instructions stored in the memory (230) and perform various processes. The communicator (220) is configured to communicate internally between internal hardware components and with external devices via one or more networks. The memory (230) also stores instructions to be executed by the processor (210). The memory (230) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). Furthermore, in some examples, the memory (230) may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be construed as meaning that the memory (230) is immovable. In some examples, a non-transitory storage medium may store data that can change over time (e.g., in random access memory (RAM) or cache memory).

[0148] although Figure 3 The hardware components of the SNM-C (130) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the SNM-C (130) may include fewer or more components. The labels or names of the components are for illustrative purposes only and do not limit the scope of the invention. One or more components may be combined to perform the same or substantially similar functions in the SNM-C (130).

[0149] Figure 4 Hardware components of an SNM-S (140) according to an embodiment are shown. The SNM-S (140) includes a processor (310), a communicator (320), a memory (330), and a push NM processing controller (340). The processor (310) is coupled to the communicator (320), the memory (330), and the push NM processing controller (340).

[0150] The push NM processing controller (340) receives the push NM from the VAL server (150). The push NM is managed during the SEAL notification management service. The push NM includes at least one of the following: VAL ID cluster information, VAL NM type, VAL NM length, and VAL NM. The VAL ID cluster information includes the VAL identifier shared by the VAL server (150) and the VAL NM. The VAL NM type includes the content type of the VAL NM shared by the VAL server (150). The VAL NM length includes the length of the VAL NM. The VAL NM includes the message received from the VAL server (150) to be notified to the VAL client (120) via the SEAL notification channel.

[0151] The push NM processing controller (340) determines that a push notification channel exists for the SNM-C (130) to receive a push NM that matches the VAL identifier shared by the VAL server (150). The VAL identifier includes the VAL UE, VAL user ID, VAL service ID, and VAL application ID.

[0152] The push NM processing controller (340) generates an HTTP POST message. The HTTP body contains a VAL NM payload that stores each push NM received from the VAL server (150) in VAL NM format. The HTTP POST message is configured to set the request URI to the push callback URL received when the notification channel is created. The HTTP POST message is configured to set the content-type header to application / vnd.3gpp.seal-notification-payload / json. The HTTP POST message is configured to set the NM payload as specified in the VAL NM list parameters. The VAL NM list parameters include at least one of the channel ID associated with the SNM-C (130) and the VAL NM list of messages received from the VAL server (150). The VAL NM list parameters are included in the HTTP request entity body as specified in Table 1 of Terms above and are serialized to a JSON structure as specified in IETF RFC 7159.

[0153] The VAL NM list includes a list of NMs. Each NM from the list of NMs represents a message received from the same or different VAL servers (150). NMs are encoded by SNM-S (140). When SNM-S (140) decides to execute a push notification message to a specific SNM-C, SNM-S (140) determines all NMs addressed to SNM-C (130), regardless of which VAL server (150) the NM was received from.

[0154] The push notification message processing controller (340) sends the generated HTTP POST request to SNM-C (130).

[0155] Optionally, the push notification message processing controller (340) receives an HTTP POST request from SNM-C (130) for creating a notification channel, wherein the request URI associated with the HTTP POST request includes the URI of SNM-S (140). The push notification message processing controller (340) processes the create notification channel request when it determines that the channel type is push and the requester identifier of the received HTTP POST request is an authorized requester. The push notification message processing controller (340) processes push channel details when it determines that the channel type is push to obtain the push callback URL of SNM-C (130). The push notification message processing controller (340) creates a notification channel response message indicating successful creation of the notification channel and sends an HTTP 200 OK response message including the notification channel response message to SNM-C (130). When NM is pushed to SNM-C (130), the push notification message processing controller (340) stores the processed push callback URL of SNM-C (130) for future use.

[0156] The push notification message processing controller (340) creates an HTTP POST request in which the request URI is set to the push callback URL of SNM-C (130), and sends the request to SNM-C (130) to push the NM addressed to SNM-C (130).

[0157] although Figure 4 The hardware components of the SNM-S (140) are shown, but it should be understood that this disclosure is not limited thereto. In other embodiments, the SNM-S (140) may include fewer or more components. The labels or names of the components are for illustrative purposes only and do not limit the scope of this disclosure. One or more components may be combined to perform the same or substantially similar functions in the SNM-S (140).

[0158] Figure 5 A method (S500) for managing push notification messages in a SEAL notification management service, implemented by an SNM-C (130) according to an embodiment, is shown. Steps (S502-S508) are performed by a push NM processing controller (240).

[0159] In step S502, when the push NM processing controller (240) receives an HTTP POST request from SNM-S (140) via the push callback URL, it matches the ID received in the channel ID parameter associated with the HTTP POST request with the channel ID stored locally at SNM-C (130). In step S504, after the push NM processing controller (240) matches the ID received in the channel ID parameter associated with the HTTP POST request with the channel ID stored locally at SNM-C (130), it sends an HTTP response to SNM-S (140). In step S506, the push NM processing controller (240) processes the VAL NM list parameters, including decoding at least one encoded VAL NM received in the HTTP request entity of the HTTP POST request. In step S508, the push NM processing controller (240) delivers the received push NM to the VAL client (120) running on the UE (110).

[0160] Figure 6 A method (S600) for managing push NM in a SEAL notification management service, implemented by SNM-S (140) according to an embodiment, is shown. Steps (S602-S608) are performed by the push NM processing controller (340).

[0161] In step S602, the push NM processing controller (340) receives a push NM addressed to a VAL client from the VAL server (150). In step S604, the push NM processing controller (340) determines that an active push notification channel exists for the SNM-C (130) to receive a push NM that matches the VAL identifier shared by the VAL server (150). In step S606, the push NM processing controller (340) generates an HTTP POST message. The HTTP body is set with a VAL NM payload, which stores each push NM received from the VAL server (150) encoded in VAL NM format. In step S608, the push NM processing controller (340) sends the generated HTTP POST message to the SNM-C (130).

[0162] The disclosed push notification process allows SNM-S (140) to easily push NM to SNM-C (130) without consuming excessive resources.

[0163] Figure 7A method (S700) for managing push callback URL NMs in the SEAL notification management service during a notification channel creation procedure call, implemented by SNM-C (130) according to an embodiment, is shown. Steps S702-S708 are performed by the push NM processing controller (240).

[0164] In step S702, after receiving a request from the VAL service for receiving a push NM via a notification channel, the push NM processing controller (240) sends an HTTP POST request to the SNM-S (140). In step S704, the push NM processing controller (240) sends an HTTP POST request to the SNM-S (140) to create a push notification channel with an associated push callback URL. In step S706, upon receiving an HTTP 200 OK message from the SNM-S (140) and sharing the SNM-S callback URL, the push NM processing controller (240) notifies the VAL service via the notification channel of a successful indication of receiving the push NM. In step S708, the push NM processing controller (240) listens for the push callback URL to receive future push NMs from the SNM-S (140).

[0165] Figure 8 A method (S800) for managing push callback URLs in the SEAL notification management service during a notification channel creation procedure call, implemented by an SNM-S (140) according to an embodiment, is shown. Steps S802-S812 are performed by the NM processing controller (340), which is also an NM processing controller.

[0166] In step S802, the push NM processing controller (340) receives an HTTP POST request from SNM-C (130) for creating a notification channel, wherein the request URI associated with the HTTP POST request includes the URI of SNM-S (140). In step S804, the push NM processing controller (340) processes the create notification channel request when it determines that the channel type is push type and the requester identifier of the received HTTP POST request is an authorized requester. In step S806, the push NM processing controller (340) processes push channel details when it determines that the channel type is push type to obtain the push callback URL of SNM-C (130). In step S808, the push NM processing controller (340) creates a notification channel response message indicating successful creation of the notification channel. In step S810, the push NM processing controller (340) sends an HTTP 200 OK response message to SNM-C (130) including the notification channel response message. In step S812, when NM is pushed to SNM-C (130), the push NM processing controller (340) stores the push callback URL of the processed SNM-C (130) for future use.

[0167] Return to reference Figure 4 The push NM processing controller (340) is implemented by analog and / or digital circuits, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, etc., and may optionally be driven by firmware.

[0168] The processor (310) may include one or more processors. The one or more processors may be general-purpose processors (such as central processing unit (CPU), application processor (AP), etc.), graphics-only processing units (such as graphics processing unit (GPU), vision processing unit (VPU)) and / or AI-specific processors (such as neural processing unit (NPU)). The processor (310) may include multiple cores and is configured to execute instructions stored in memory (330).

[0169] The processor (310) is configured to execute instructions stored in the memory (330) and perform various processes. The communicator (320) is configured for internal communication between internal hardware components and for communication with external devices via one or more networks. The memory (330) also stores instructions to be executed by the processor (310). The memory (330) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). Furthermore, the memory (330) may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be construed as meaning that the memory (330) is immovable. In some examples, a non-transitory storage medium may store data that can change over time (e.g., in random access memory (RAM) or cache memory).

[0170] Embodiments herein can be described and illustrated based on blocks that perform one or more of the described functions. These blocks, which may be referred to herein as managers, units, modules, hardware components, etc., are physically implemented by analog and / or digital circuitry (such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuitry, etc.) and may optionally be driven by firmware. The circuitry may, for example, be embodied in one or more semiconductor chips or on a substrate support such as a printed circuit board. The circuitry constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware performing some functions of the block and a processor performing other functions of the block. Each block of an embodiment may be physically divided into two or more interactive and discrete blocks without departing from the scope of this disclosure. Similarly, the blocks of an embodiment may be physically combined into more complex blocks without departing from the scope of this disclosure.

[0171] The various actions, blocks, steps, etc. in the flowcharts (S500-S800 disclosed herein) can be executed in the order they are presented, in different orders, or simultaneously. Without departing from the scope of this disclosure, some of the actions, blocks, steps, etc., can be omitted, added, modified, or skipped.

[0172] The embodiments disclosed herein can be implemented by at least one software program that runs on at least one hardware device and performs network management functions to control the element.

[0173] Although this disclosure has been shown and described with reference to various embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made without departing from the spirit and scope of this disclosure as defined by the appended claims and their equivalents.

Claims

1. A method for managing push notification messages in a Service Enabler Architecture Layer Notification Management (SNM) service, comprising: The SNM client (SNM-C) receives Hypertext Transfer Protocol (HTTP) POST requests from the SNM server (SNM-S) via a push callback Uniform Resource Identifier (URI); The SNM-C will match the ID received in the channel identifier (ID) parameter associated with the HTTP POST request with the channel ID stored locally at the SNM-C. After the ID received in the channel ID parameter associated with the HTTP POST request is matched with the channel ID stored locally at SNM-C, SNM-C sends an HTTP response to SNM-S. The Vertical Application Layer (VAL) notification message list parameter is processed by SNM-C. The VAL notification message list parameter includes at least one encoded VAL notification message received in the HTTP request entity of the HTTP POST request. as well as The push notification message received from the VAL notification message list parameters by SNM-C is delivered to the VAL client running on the user equipment (UE).

2. The method according to claim 1, wherein, The decoded form of the push notification message is delivered to a VAL client running on the UE, the VAL client having a VAL ID that matches the VAL ID cluster information parameters associated with the push notification message.

3. The method according to claim 1, wherein, The VAL notification message list parameters also include the channel ID and at least one item from the VAL notification message list.

4. The method according to claim 3, wherein, The channel ID is the ID corresponding to the notification channel of SNM-C.

5. The method according to claim 3, wherein, The VAL notification message list includes a list of notification messages, and Each notification message represents a message received from the VAL server, which is a message encoded and pushed by SNM-S.

6. The method according to claim 1, wherein, Push notification messages are managed using the SEAL notification management service, and Each push notification message includes at least one of the following: VAL ID cluster information, VAL notification message type, VAL notification message length, and VAL notification message.

7. The method according to claim 6, wherein, VAL identifier cluster information includes the VAL ID and VAL notification messages shared by the VAL servers. The VAL notification message types include the content types of VAL notification messages shared by the VAL server. The VAL notification message length includes the length of the VAL notification message, and The VAL notification message includes messages received from the VAL server that are to be notified to the VAL client via the Service Enabler Architecture Layer (SEAL) notification channel.

8. A method for managing push notification messages in a Service Enabler Architecture Layer Notification Management (SNM) service, comprising: Push notification messages are received by the SNM server (SNM-S) from the vertical application layer (VAL) server; The SNM-S determines the existence of a push notification channel with the SNM client (SNM-C) to receive push notification messages that match the VAL identifier (ID) shared by the VAL server; SNM-S generates a Hypertext Transfer Protocol (HTTP) POST message, wherein the HTTP body is set with a VAL notification message payload, the VAL notification message payload storing each push notification message received from the VAL server in the form of a VAL notification message; as well as The generated HTTP POST message is sent from SNM-S to SNM-C.

9. The method according to claim 8, wherein, The VAL identifier includes at least one of the following: VAL User Equipment, VAL User ID, VAL Service ID, and VAL Application ID.

10. The method according to claim 8, in, SNM-S creates an HTTP POST message, where the request URI is set to the Uniform Resource Identifier (URI) of the push callback received when the notification channel is created. The HTTP POST message is configured with the content type header of the application / vnd.3gpp.seal-notification-payload / json message, and The SNM-S message generates a notification message payload as specified in the VAL notification message list parameters.

11. The method according to claim 10, wherein, The VAL notification message list parameters include the channel ID associated with SNM-C and at least one of the VAL notification message lists of messages received from the VAL server.

12. The method according to claim 8, wherein, Push notification messages are managed in the SEAL notification management service. Each push notification message includes at least one of the following: VAL ID cluster information, VAL notification message type, VAL notification message length, and VAL notification message.

13. The method according to claim 12, wherein, VAL ID cluster information includes VAL identifiers and VAL notification messages shared by VAL servers. The VAL notification message type includes the content type of the VAL notification message shared by VAL servers. The VAL notification message length includes the length of the VAL notification message. The VAL notification message includes a message received from the VAL server that is to be notified to the VAL client via the service enabler architecture layer notification channel.

14. A service enabler architecture layer notification management client (SNM-C), comprising: processor; Memory; and A push notification message processing controller, coupled to a processor and a memory, is configured to: Receive Hypertext Transfer Protocol (HTTP) POST requests from the SNM server (SNM-S) by pushing a Uniform Resource Identifier (URI) callback; The ID received in the channel identifier (ID) parameter associated with the HTTP POST request will be matched with the channel ID stored locally at SNM-C; After matching the ID received in the channel ID parameter associated with the HTTP POST request with the channel ID stored locally at SNM-C, an HTTP response is sent to SNM-S; Processing the list of Vertical Application Layer (VAL) notification messages includes decoding at least one encoded VAL notification message received in the HTTP request entity of an HTTP POST request; as well as Each push notification message received from the VAL notification message list parameter will be delivered to the VAL client running on the user equipment (UE).

15. A Service Enabler Architecture Layer Notification Management Server (SNM-S), comprising: processor; Memory; and A push notification message processing controller, coupled to a processor and a memory, is configured to: Receive push notification messages from the Vertical Application Layer (VAL) server; Determine the existence of a push notification channel with the Service Enabler Architecture Layer Notification Management Client (SNM-C) to receive push notification messages that match the VAL identifier (ID) shared by the VAL server; Generate a Hypertext Transfer Protocol (HTTP) POST message. The HTTP POST message has an HTTP body, which is set with a VAL notification message payload. The VAL notification message payload stores a push notification message received from the VAL server and encoded in the form of a VAL notification message. as well as Send the generated HTTP POST request to SNM-C.

Images