Method and apparatus for media session management in wireless communication, computer readable medium
By introducing a media session management module and network resource management in the SEAL architecture layer into the VAL server, the problem of low efficiency in media session management for vertical applications in wireless communication systems is solved, and the rational allocation of network resources and high efficiency in session establishment are achieved.
Patent Information
- Application Number
- CN202180031395.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2021-10-12
- Filing Date
- 2021-10-14
- Publication Date
- 2026-02-13
- Estimated Expiration
- 2041-10-14
AI Technical Summary
Existing wireless communication systems struggle to effectively manage network resources in media session management for vertical applications, resulting in inefficient session establishment and resource waste.
By introducing a media session management module into the VAL server, the Session Description Protocol (SDP) information is obtained, network resource requests are sent to the NRM server, evaluations are received and media sessions are established or terminated based on the evaluations, and resource allocation is performed using the network resource management function of the SEAL architecture layer.
It enables media session management for vertical applications, improves session establishment efficiency and resource utilization, and ensures the accuracy of media sessions and the rational allocation of network resources.
Smart Images

Figure CN115461734B_ABST
Abstract
Description
[0001] INCORPORATED BY REFERENCE
[0002] This application claims priority to U.S. Patent Application No. 17 / 499,528, filed October 12, 2021, entitled “Methods and Apparatus for Media Session Management for Service Enabler Architecture Layer (SEAL) Architecture,” which claims priority to U.S. Provisional Application No. 63 / 172,058, filed April 7, 2021, entitled “Methods and Apparatus to Support Session Description Protocol (SDP) Parameters for Media Session Management for 3GPP Service Enabler Architecture Layer (SEAL) Architecture.” The entire disclosure of the prior applications is hereby incorporated by reference in its entirety. TECHNICAL FIELD
[0003] Embodiments of the present disclosure describe a service enabler layer that generally relates to supporting vertical applications running over a wireless network. BACKGROUND
[0004] The background description provided herein is intended to generally present the context of the present disclosure. The work of the presently named inventors, to the extent the work is at all
[0005] Wireless communication systems are designed with advanced built-in functionality to support enterprise divisions or vertical industries, such as healthcare, automotive, smart factory, mission critical communications, and the like. Vertical application standards are being developed to quickly deploy vertical services based on common services provided by a wireless network. A vertical domain can be an industry or a group of enterprises that produce similar products or services. A vertical application provides services or functions that are useful in a particular vertical domain. SUMMARY
[0006] Aspects of the present disclosure provide a method of media session management in wireless communications, the method comprising: obtaining session description protocol (SDP) information within a session initiation protocol (SIP) payload associated with a media session; sending, by a media session management module of a vertical application layer (VAL) server, a network resource request including the SDP information to a network resource management (NRM) server, the NRM server being a service enabler architecture layer (SEAL) server, the network resource request requesting network resources; receiving, by the VAL server, an evaluation of the network resource request from the NRM server; and establishing or terminating the media session in the media session management module of the VAL server based on the received evaluation.
[0007] Aspects of the disclosure provide a vertical application layer (VAL) server for media session management in wireless communications. The VAL server can include processing circuitry. In embodiments, the VAL server can include a media session management module that includes the processing circuitry. Session description protocol (SDP) information within a session initiation protocol (SIP) offer associated with a media session can be obtained. The processing circuitry of the media session management module of the VAL server can originate a network resource request including the SDP information to a network resource management (NRM) server. The NRM server can be a service enabler architecture layer (SEAL) server. The network resource request can request network resources. The VAL server can receive an evaluation of the network resource request from the NRM server. The media session can be established or terminated in the media session management module of the VAL server based on the received evaluation.
[0008] The evaluation can include (i) rejecting the network resource request or (ii) granting the network resource request.
[0009] In an example, the NRM server evaluates the network resource request to grant the network resource request or reject the network resource request.
[0010] In embodiments, in response to granting the network resource request, the NRM server can allocate the requested network resources and the media session can be established based on the allocated network resources.
[0011] In embodiments, in response to the NRM server rejecting the network resource request, the media session can be terminated.
[0012] In embodiments, the requested network resources are at least one of a network bandwidth requirement and a bit rate requirement.
[0013] In embodiments, the media session is a SIP session.
[0014] In an example, the evaluation is based on one of a maximum bandwidth allowed for the media session and a maximum bit rate allowed for the media session.
[0015] In an example, the network resource request further includes an identification of the VAL server and an identification of a VAL user equipment (UE).
[0016] This disclosure also provides an apparatus for media session management in wireless communication, comprising: an acquisition module for acquiring Session Description Protocol (SDP) information within a Session Initiation Protocol (SIP) payload associated with a media session; a transmission module for sending a network resource request including the SDP information to a Network Resource Management (NRM) server, wherein the NRM server is a Service Enablement Architecture Layer (SEAL) server, and the network resource request requests network resources; a receiving module for receiving an evaluation of the network resource request from the NRM server; and a media session processing module for establishing or terminating the media session in the media session management module of the VAL server based on the received evaluation.
[0017] This disclosure also provides a non-volatile computer-readable medium for storing instructions that, when executed by a computer, cause the computer to perform the method for media session management in wireless communication. Attached Figure Description
[0018] Other features, properties, and various advantages of the disclosed subject matter will become further apparent from the following detailed description and accompanying drawings, wherein:
[0019] Figure 1 A general online network functional model according to embodiments of this disclosure is shown.
[0020] Figure 2 An exemplary workflow for media session management according to embodiments of this disclosure is shown.
[0021] Figure 3 An exemplary workflow for media session management according to embodiments of this disclosure is shown.
[0022] Figure 4 An exemplary workflow for media session management according to embodiments of this disclosure is shown.
[0023] Figure 5 An exemplary workflow for media session management according to embodiments of this disclosure is shown.
[0024] Figure 6 A flowchart illustrating a process according to some embodiments of the present disclosure is shown.
[0025] Figure 7 This is a schematic diagram of a computer system according to an embodiment. Detailed Implementation
[0026] Embodiments of the present disclosure implement a service enabling layer for supporting vertical applications (or verticals). In the present disclosure, the service enabling layer can be referred to as a service enabling architecture layer (SEAL). The SEAL can provide a set of common functions (or services) for use by multiple verticals to accelerate the development and deployment of vertical applications. For example, commonly used auxiliary services can be captured into the SEAL and shared by multiple vertical applications, instead of developing auxiliary services specific to each vertical. With vertical applications, the use of all SEAL services can be optional. A vertical application can decide to use any subset of services from the SEAL.
[0027] In some embodiments, a functional model for the SEAL can be organized into a common SEAL service functional model and a plurality of specific SEAL service functional models. The common SEAL service functional model can be used as a reference model for the specific SEAL service functional models. The common functional model can include on-network network functional model and off-network network functional model. In various embodiments, the SEAL services provided for supporting the vertical application layer can include location management, group management, configuration management, identity management, key management, network resource management, etc.
[0028] Figure 1 A common on-network network functional model (100) is shown in accordance with embodiments of the present disclosure. The model (100) can include four types of functional entities: a vertical application layer (VAL) client (111), a VAL server (121), a SEAL client (112), and a SEAL server (122). The number of each type of functional entity in the model (100) can be one or more. The VAL client and VAL server entities can belong to a VAL (101). The SEAL client and SEAL server entities can belong to a SEAL (102). The VAL client (111) and the SEAL client (112) can be included in a user equipment (UE) (110). The model (100) further includes a wireless network system (140) (e.g., a third generation partnership project (3GPP) network system). These elements can be coupled together as shown. Figure 1
[0029] In the VAL (101), the VAL client (111) can communicate with the VAL server (121) through a VAL-UU reference point (134) corresponding to a VAL-UU interface. In an example, the VAL-UU interface supports unicast and multicast delivery modes.
[0030] The SEALs (102) can provide various services for the VALs (101). One or more SEAL clients can communicate with one or more SEAL servers through one or more SEAL-UU reference points (133) corresponding to a SEAL-UU interface. The SEAL-UU interface can support both unicast and multicast delivery modes. One or more SEAL clients can provide service enabler layer support functions for one or more VAL clients through a SEAL-C reference point (131) corresponding to a SEAL-C interface. One or more VAL servers can communicate with one or more SEAL servers through one or more SEAL-S reference points corresponding to a SEAL-S interface. One or more SEAL servers (122) can communicate with an underlying wireless network system (e.g., a 3GPP network system) (140) using a 3GPP interface (135) specified by the wireless network system (e.g., a 3GPP network system) 140.
[0031] For a particular service (e.g., a location management service), a particular SEAL client and a particular SEAL server, as well as a particular SEAL-UU reference point and a particular network interface of a wireless network system (e.g., a 3GPP network system) can form or belong to a particular online network function model.
[0032] In some embodiments, to support distributed SEAL server deployment, a SEAL server can interact with another SEAL server for the same SEAL service through a so-called SEAL-E reference point (not shown in Figure 1 ). A SEAL server can interact with another SEAL server through a so-called SEAL-X reference point (not shown in Figure 1 ) for inter-service communication. A SEAL server can interact with a VAL user database for storing and retrieving user profiles through a VAL-UDB reference point.
[0033] In various embodiments, functional entities in a VAL system (e.g., including VALs 101 and SEALs 102) can provide application control and media specific functions to support one or more VAL services. In Figure 1 an example, a VAL client (111) (e.g., a vehicle-to-everything (V2X) client) can provide client-side functions corresponding to a vertical application (e.g., a drone (UAV) client, a V2X client). The VAL client (111) can support interaction of the vertical application with one or more SEAL clients (112). A VAL server (121) (e.g., a UAV server, a V2X server) can provide server-side functions corresponding to the vertical application.
[0034] In Figure 1In examples, a SEAL client (112) can provide client-side functionality corresponding to a particular SEAL service (e.g., location management, network resource management, etc.). The SEAL client (112) can support interaction with one or more VAL clients (111). The SEAL client can also support interaction with a corresponding SEAL client between two UEs. A SEAL server (122) can provide server-side functionality corresponding to a particular SEAL service. The SEAL server (122) can support interaction with one or more VAL servers (121). The SEAL server can also support interaction with a corresponding SEAL server in a distributed SEAL deployment.
[0035] The functional entities in the model (100) can be implemented in various ways in different embodiments. For example, the functional entities can be implemented in a distributed manner or in a centralized manner. The functional entities can be implemented as software or a combination of software and hardware.
[0036] In examples, a VAL user database (not shown) can contain information of user profiles associated with VAL services provided by a VAL service provider. Typically, each VAL service can have a corresponding user database, such as a mission critical push to talk (MCPTT) user database, a mission critical video (MCVideo) user database, and a mission critical data (MCData) user database. Figure 1
[0037] In some embodiments, interaction related to VAL (101) support functions between a VAL client (111) and a VAL server (121) is supported by a VAL-UU reference point (134). In examples, the VAL-UU reference point (134) is an instance of the Uu reference point described in 3GPP TS 23.401 and 3GPP TS 23.501. In some embodiments, interaction related to VAL support functions between VAL clients of two UEs can be supported by a VAL-PC5 reference point (not shown). For example, the VAL-PC5 reference point can be an instance of the PC5 reference point described in 3GPP TS 23.303.
[0038] In some embodiments, the interaction between a SEAL client (112) and a corresponding SEAL server (122) is supported by a SEAL-UU reference point (133). The specific SEAL service reference point corresponding to SEAL-UU (133) can be specified in the specific SEAL service functional model. In some embodiments, the interaction between SEAL clients of two VAL UEs can be supported by a SEAL-PC5 reference point (not shown). The specific SEAL service reference point corresponding to SEAL-PC5 can be specified in the specific SEAL service functional model.
[0039] In some embodiments, the interaction between one or more VAL clients (111) and one or more SEAL clients (112) within a VAL UE (110) is supported by a SEAL-C reference point (131). The specific SEAL service reference point corresponding to SEAL-C (131) can be specified in the specific SEAL service functional model.
[0040] In some embodiments, the interaction between a VAL server (121) and a SEAL server (132) is supported by a SEAL-S reference point (132). The specific SEAL service reference point corresponding to SEAL-S (132) can be specified in the specific SEAL service functional model.
[0041] In some embodiments, the interaction between SEAL servers of the same type (e.g., providing the same type of SEAL service) is supported by a SEAL-E reference point (not shown). The specific SEAL service reference point corresponding to SEAL-E is specified in the specific SEAL service functional model.
[0042] In some embodiments, the interaction between SEAL servers of different types can be supported by a SEAL-X reference point. Examples of specific reference points corresponding to SEAL-X reference points can include a reference point SEAL-X1 between a key management server and a group management server, a reference point SEAL-X2 between a group management server and a location management server.
[0043] Reference point VAL-UDB exists between a VAL user database and a SEAL server. Reference point VAL-USB can be used to store user profile data in a specific VAL user database and to obtain a user profile from a specific VAL user database for further configuration in a UE.
[0044] In various embodiments, different identities can be configured and used in a VAL system developed based on the model (100). In some embodiments, a VAL user can present a user identity (user ID) to an identity management server in the SEAL (102) during a user authentication transaction to provide the identity management client with a means for VAL service authentication. Typically, since identity management is a public SEAL service, the identity management server uses a set of credentials (e.g., biometric, secure ID, username / password) that are not necessarily tied to a single VAL service. The user credentials uniquely identify the VAL user to the identity management server. For example, specific security and authentication mechanisms required for using a user ID are specified in 3GPP TS 33.434.
[0045] In some embodiments, a VAL user ID is a unique identifier representing a VAL user within a VAL service. For example, a VAL user ID can be a uniform resource identifier (URI). The VAL user ID is used for authentication and authorization purposes to provide VAL services to the VAL user through a VAL UE. The VAL user ID also represents the VAL service provider with which the VAL user has a VAL service agreement. A VAL user can have a VAL service agreement with a VAL service provider, thereby obtaining a unique VAL user ID per VAL service provider. The VAL user ID can be used to access SEAL services.
[0046] In some embodiments, a VAL UE ID is a unique identifier representing a VAL UE within a VAL service. For example, a VAL UE ID for a V2X service maps to a station ID specified in ETSI TS 102 894-2. The VAL UE ID is used to address the VAL UE for sending VAL messages.
[0047] In some embodiments, a VAL service ID is a unique identifier representing a VAL service. A VAL server provides a list of VAL services to a VAL user or VAL UE. Each VAL service is uniquely identified by a VAL service ID, which is an identifier of a VAL application that provides the VAL service. The VAL service ID can be used for policy mapping, QoS handling of VAL communications, and VAL message distribution. For example, an identifier for a V2X service (e.g., ITS-AID or PSID specified in ETSI TS 102 965 and ISO TS 17419) can be used as a V2X service ID.
[0048] In some embodiments, the VAL group ID is a unique identifier within a VAL service that represents a group of VAL users or VAL UEs under the VAL service. The group of VAL users can belong to the same or different VAL service providers. The VAL group ID represents the VAL application server that defines the group.
[0049] In some embodiments, the VAL system ID is a globally unique identifier that represents the VAL system. In some embodiments, the VAL flow ID is an identifier used by the VAL server to identify a VAL flow.
[0050] In various embodiments, the SEAL architecture as described above can support deployment of SEAL services within and / or outside of a public land mobile network (PLMN). The SEAL architecture can also support centralized and distributed deployment of vertical applications. A mobile network operator (MNO) can utilize the appropriate deployment model that suits its business as needed.
[0051] The deployment models can involve multiple entities, such as VAL users, VAL service providers, SEAL providers, and PLMN operators. For example, in a possible deployment model, one or more SEAL servers can be deployed within the PLMN operator domain, and vertical application servers can be deployed within the VAL service provider domain. The SEAL servers can also interact with another SEAL server of the same SEAL service deployed in a different PLMN operator domain using the SEAL-E interface.
[0052] There can be multiple business relationships between the entities involved in the deployment. Based on service-specific agreements, the VAL users belong to the VAL service provider domain. The VAL service provider and the home PLMN operator can belong to the same organization. The VAL service provider can have a service agreement with the SEAL service provider. The VAL service provider, the SEAL service provider, and the home PLMN operator can also belong to the same organization. If the VAL service provider and the home PLMN operator do not belong to the same organization, they can have a service agreement.
[0053] With reference to Figure 1 , the SEAL architecture can provide network resource management. More specifically, the SEAL client (112) is a network resource management (NRM) client (112). The SEAL server (122) is an NRM server (122). The NRM client (112) functional entity can act as a VAL client (111) for managing network resources. The NRM client (112) can interact with the NRM server (122).
[0054] The NRM server (122) functional entity can provide management of network resources (e.g., unicast, multicast) of a wireless network system (e.g., a 3GPP network system) (140) to support VAL clients (111).
[0055] Interactions related to network resource management functions between the NRM client (112) and the NRM server (122) can be supported by a SEAL-UU reference point (133) (also known as an NRM-UU reference point). Interactions related to network resource management functions between one or more VAL servers (121) and the NRM server (122) can be supported by a SEAL-S reference point (132) (also known as an NRM-S reference point).
[0056] In some embodiments, the interaction between one or more VAL clients (111) and one or more NRM clients (112) within the VAL UE (110) is supported by a SEAL-C reference point (131) (also known as an NRM-C reference point).
[0057] In various real-time media communications, the combination of Session Initiation Protocol (SIP) and Session Description Protocol (SDP) can be used for session initialization and media parameter negotiation. Before the actual media service passes through the network, such as in a wireless network system (140) (e.g., a 3GPP network system), both protocol data can be carried in the control plane. SDP can be carried as a SIP payload and can include media codec-related parameters (e.g., all media codec-related parameters). SDP can be used to transmit information about the media stream and provide sufficient information to enable joining and participating in a media session, for example, in unicast scenarios.
[0058] In this embodiment, a key piece of information carried in the SDP is the potential bandwidth usage for a specific media stream. In the example, for a payload (e.g., a UAV media-dependent payload), knowing the bandwidth that the payload (e.g., a UAV media-dependent payload) intends to use is crucial for resource allocation within the network (e.g., a wireless network system (140) (e.g., a 3GPP network system)).
[0059] SEAL can support SIP for session establishment. According to embodiments of this disclosure, one or more SDP data points can be added to address unicast media session monitoring and management.
[0060] For media session management, the SDP in the SIP packet can carry important information about media parameters, as shown below.
[0061] v = 0
[0062] o=Clientl 2398026505 2307593197 IN IP4 100.200.130.140
[0063] S=Clientl Audio Session
[0064] b=AS:64
[0065] b=RS:800
[0066] b=RR:2400
[0067] c=IN IP4 10.11.12.13
[0068] t=0 0
[0069] m=audio 15010 RTP / AVP 0 101
[0070] a=rtpmap:0 PCMU / 8000
[0071] a=rtpmap:101 telephone-event / 8000
[0072] a=sendrecv
[0073] The SDP information shown above will be sent from the VAL server (121) to the NRM server (122) through the NRM-S reference point (132).
[0074] The parameter included in the SDP is bandwidth information. The bandwidth information can indicate a maximum bandwidth. The maximum bandwidth can limit a successful establishment of a media session.
[0075] In an example, B=AS:bitrate can indicate a maximum bitrate allowed for a media session. For example, b=as:64 means that the media session allows a maximum bitrate of 64 kb / s.
[0076] Figure 2 An example workflow (or process) (200) for media session management according to embodiments of the present disclosure is shown. In an example, Figure 2 A resource request at the time of VAL service communication establishment is shown. The workflow (200) can be implemented by a VAL server (221), an NRM server (222), a SIP core (223), and a network system (240). In an embodiment, one or more resources (or one or more network resources) requested in the workflow (200) can include one or more unicast resources, and the workflow (200) can be used for unicast resource management using the SIP core (223).
[0077] The workflow (200) can specify how to request network resources at VAL service communication establishment. In an example, if concurrent sessions are used, the NRM server (222) can utilize resource sharing capabilities specified for underlying network policy and charging functions. The resource request can include application type, bandwidth, priority, application identifier, resource sharing information, etc. In an example, the requested one or more network resources include bandwidth (e.g., maximum bandwidth for the application).
[0078] The workflow (200) can be appropriately adjusted and applied to any suitable type of session establishment using network resource requests. In an example, Figure 2 A signaling procedure for requesting resources at session establishment is shown.
[0079] In an example, prior to step (S241), the precondition that the VAL client has requested VAL service communication with the VAL server (221) is met.
[0080] At (S241), the VAL server (221) can send a resource request (also referred to as a network resource request) to the NRM server (222) to request network resources, e.g., bandwidth for the application. The VAL server (221) can be any suitable server for vertical applications. The VAL server (221) can be a drone (UAV) server for UAV applications, a V2X server for V2X applications, etc.
[0081] At (S242), the NRM server (222) can evaluate the demand for network resources. In an example, the NRM server (222) further evaluates the use of resource sharing.
[0082] At (S243), the NRM server (222) can send a session progress request containing the resource request to the SIP core (223).
[0083] The SIP core (223) can include multiple sub-entities responsible for registration, service selection, and routing in the signaling control plane. In an example, the SIP core (223) is a 3GPP IP Multimedia Core Network Subsystem.
[0084] Data related to the functions of the SIP core (223), such as data for application service selection, identification of service registrar, or authentication related information, can be provided by the PLMN operator responsible for the bearer plane. Thus, the SIP database as a data source can be part of a Home Subscriber Server (HSS). Alternatively, the data can be provided by the VAL service provider, and the data source can be the SIP database of the VAL service provider.
[0085] The SIP core local inbound / outbound proxy functional entity can act as an inbound proxy and an outbound proxy for SIP transactions. The SIP core local inbound / outbound proxy functional entity can provide one or more of the following functions: NAT traversal; resource control; routing / forwarding of requests and responses to user agents; SIP signaling security; and discovery and address resolution depending on the policy of the PLMN operator.
[0086] At (S244), a policy control and charging (PCC) procedure can be initiated from the SIP core local inbound / outbound proxy (223).
[0087] At (S245), the SIP core local inbound / outbound proxy (223) can send an OK message to the NRM server (222).
[0088] At (S246), the NRM server (222) can send a resource response to the VAL server (221).
[0089] At (S247), a VAL service communication can be established using unicast bearer, e.g., based on the allocated resources.
[0090] As described with reference to Figure 1 The VAL server (221) can be similar or identical to the VAL server (121), the NRM server (222) can be similar or identical to the NRM server (122), and the network system (240) can be similar or identical to the network system (140). In an example, the network system (240) is a 3GPP network. Therefore, detailed descriptions of the VAL server (221) and the NRM server (222) are omitted for brevity.
[0091] The workflow (200) can be adjusted as appropriate. One or more steps in the workflow (200) can be modified and / or omitted. One or more additional steps can be added. Any suitable implementation order can be used.
[0092] Usage of SDP for session negotiation (e.g., public usage of SDP) can occur in unicast scenarios, multicast scenarios, and the like. In embodiments, the VAL media server uses SDP information in unicast scenarios and multicast scenarios. In some examples, in a network deployment, SDP usage for unicast traffic can be more frequent than for multicast. In some examples, the NRM server does not have the option of the VAL server passing SDP information to the NRM server for unicast traffic. According to embodiments of the disclosure, SDP information can be added to the information flow from the VAL server to the NRM-S or NRM server. In some examples, without adding SDP information to the information flow, a media session established (or initiated) by the VAL client using SDP cannot be addressed correctly.
[0093] According to embodiments of the disclosure, a resource request (or network resource request) can include SDP information as described in Table 1 below to support unicast SDP / SIP session establishment.
[0094] Table 1 describes an information flow of a resource request from a VAL server (e.g., VAL server (121) or (221)) to a NRM server (e.g., NRM server (222)) for unicast resources.
[0095] Table 1 includes a resource request with SPD information
[0096]
[0097] As shown in Table 1, the resource request can include a plurality of information elements including a requester identification, a VAL user identifier (ID) or VAL UE ID, VAL service requirement information, SDP information, and the like. The requester identification can describe an identification of the VAL server that performs the request (or resource request). The VAL user ID or VAL UE ID can describe an identification of the VAL user or VAL UE. The VAL service requirement information can describe VAL service requirements (e.g., VAL service ID, bit rate) for unicast resources. The SDP information can describe SDP with media and application control information (e.g., codec, bandwidth, protocol id, forward error correction (FEC) information) that applies to the group using this bearer. In examples, the requester identification and VAL user ID are mandatory with a mandatory (“M”) status, and the VAL service requirement information and SDP information are optional with an optional (“O”) status. When the VAL service requirement information is not included, the NRM server can consider the VAL service requirements for unicast resources by default.
[0098] Figure 3 An exemplary workflow (or process) (300) for media session management according to embodiments of the disclosure is shown. In examples, Figure 3Resource requests at VAL service communication establishment are shown. The workflow (300) can be implemented by the VAL server (221), the NRM server (222), and the SIP core (223). In an embodiment, the one or more resources (or one or more network resources) requested in the workflow (300) can include one or more unicast resources, and the workflow (300) can be used for unicast resource management using the SIP core (223).
[0099] The workflow (300) can specify how to request network resources at VAL service communication establishment. The resource request can include application type, bandwidth, priority, application identifier, resource sharing information, etc. In an example, the one or more network resources requested include bandwidth (e.g., maximum bandwidth of the application).
[0100] The workflow (300) can be adjusted and applied as appropriate for any suitable type of session establishment using network resource requests. In an example, Figure 3 Signaling procedures for requesting resources at session establishment or session initialization are shown.
[0101] At (S310), the VAL server (221) (e.g., processing circuitry of the VAL layer (221)) can send a request for one or more resources (also referred to as network resource request) to the NRM server (222) to request one or more network resources, such as bandwidth for an application (e.g., UAV application, V2X application). The VAL server (221) can be any suitable server for vertical applications. The VAL server (221) can be a UAV server for UAV applications, a V2X server for V2X applications, etc. In an example, the request can include SDP information (e.g., network bandwidth requirement or bandwidth), as described in Table 1.
[0102] Upon receiving the network resource request, the NRM server (222) can evaluate the demand for network resources, as described in (S242).
[0103] At (S320), the NRM server (222) can reject the network resource request. The rejection of the network resource request can be sent from the NRM server (222) to the VAL server (221).
[0104] At (S330), in response to the rejection of the network resource request, a media session (e.g., SIP media session or SIP session) can be terminated.
[0105] The workflow (300) illustrates an example of how a VAL server (221) (e.g., a UAE server) requests a NRM server (222) to complete a session establishment request. In an example, prior to step (S310), the preconditions are met that a VAL client has requested a VAL service communication with the VAL server (221). For example, for a UAV application, a UAV attempts to establish a media session (e.g., a SIP session) between a UAV media payload and a UAV-C or a USS / UTM through a UAV server using a 3GPP core network, and indicates resource requirements of the media session using SIP and SDP.
[0106] The workflow (300) can be adjusted as appropriate. One or more steps in the workflow (300) can be modified and / or omitted. One or more additional steps can be added. Any suitable implementation order can be used.
[0107] Figure 4 An example workflow (or procedure) (400) for media session management is illustrated in accordance with an embodiment of the present disclosure. In an example, Figure 4 A resource request at VAL service communication establishment is illustrated. The workflow (400) can be implemented by a VAL server (221), a NRM server (222), and a SIP core (223). In an embodiment, one or more resources (or one or more network resources) requested in the workflow (400) can include one or more unicast resources, and the workflow (400) can be used for unicast resource management using the SIP core (223).
[0108] The workflow (400) can specify how network resources are requested at VAL service communication establishment. The resource request can include application type, bandwidth, priority, application identifier, resource sharing information, etc. In an example, the one or more network resources requested include bandwidth (e.g., maximum bandwidth of the application).
[0109] The workflow (400) can be adjusted as appropriate and applied to any suitable type of session establishment using network resource requests. In an example, Figure 4 A signaling procedure for requesting resources at session establishment or session initialization is illustrated.
[0110] At (S410), the VAL server (221) (e.g., processing circuitry of the VAL layer (221)) can send a request for one or more resources (also referred to as a network resource request) to the NRM server (222) to request one or more network resources, e.g., bandwidth for an application (e.g., a UAV application, a V2X application). The VAL server (221) can be any suitable server for vertical applications. The VAL server (221) can be a UAV server for UAV applications, a V2X server for V2X applications, etc. In an example, the request can include SDP information (e.g., network bandwidth requirement or bandwidth), as described in Table 1.
[0111] Upon receiving the network resource request, the NRM server (222) can evaluate the demand for network resources, as described in (S242).
[0112] At (S420), the NRM server (222) can grant the network resource request. The grant of the network resource request can be sent from the NRM server (222) to the VAL server (221). The requested one or more network resources can be allocated.
[0113] At (S430), in response to the grant of the network resource request, a media session (e.g., a SIP media session or a SIP session) can be established, and unicast data traffic can start, e.g., between the UE (224) and the SIP core (223).
[0114] The workflow (400) illustrates an example of how a VAL server (221) (e.g., a UAV server) requests a NRM server (222) to complete a session establishment request. In an example, prior to step (S410), the preconditions that a VAL client has requested a VAL server (221) for VAL service communication are met. For example, for a UAV application, a UAV attempts to establish a media session (e.g., a SIP session) between a UAV media payload and a UAV-C or a USS / UTM through a UAV server using a 3GPP core network, and indicates resource requirements for the media session using SIP and SDP.
[0115] The workflow (400) can be adjusted as appropriate. One or more steps in the workflow (400) can be modified and / or omitted. One or more additional steps can be added. Any suitable implementation order can be used.
[0116] References Figures 3-4The described workflows (300) and (400) can be adjusted or combined in any suitable order or in any suitable manner. For example, one or more steps in the workflow (300) can be adjusted and / or one or more steps in the workflow (400) can be adjusted. The following can be combined: (i) one or more adjusted or original steps from the workflow (300), and (ii) one or more adjusted or original steps from the workflow (400). Figure 5 Examples of such combinations are shown in the following.
[0117] Figure 5 An example workflow (or process) (500) for media session management according to embodiments of the disclosure is shown. In an example, Figure 5 to request resources at VAL service communication establishment. The workflow (500) can be implemented by the VAL server (221), the NRM server (222), and the SIP core (223). In an embodiment, the one or more resources (or one or more network resources) requested in the workflow (500) can include one or more unicast resources, and the workflow (500) can be used for unicast resource management using the SIP core (223).
[0118] The workflow (500) can specify how to request network resources at VAL service communication establishment. The resource request can include application type, bandwidth, priority, application identifier, resource sharing information, etc. In an example, the one or more network resources requested include bandwidth (e.g., maximum bandwidth for an application).
[0119] The workflow (500) can be adjusted as appropriate and applied to any suitable type of session establishment using network resource requests. In an example, Figure 5 A signaling procedure for requesting resources at session establishment or session initialization is shown.
[0120] At (S510), the VAL server (221) (e.g., processing circuitry of the VAL layer (221)) can send a request (also referred to as a network resource request) for one or more network resources to the NRM server (222) to request one or more network resources, such as bandwidth for an application (e.g., a UAV application, a V2X application). The one or more network resources can also be referred to as one or more session resources.
[0121] The VAL server (221) can be any suitable server for a vertical application. The VAL server (221) can be a UAV server for a UAV application, a V2X server for a V2X application, etc. In the example, the VAL server (221) (e.g., a UAV server) uses SDP in the SIP payload to request media session initialization. This network resource request can be referred to as a SIP session request.
[0122] In (S510), after receiving a network resource request, the NRM server (222) can evaluate the network resource request, such as the demand for network resources, similar to that described in (S242). The evaluation may include determining whether to grant or deny the network resource request. In an embodiment, it is determined to deny the network resource request, for example... Figure 3 As shown in the example. In this embodiment, determining whether to grant a network resource request, for example... Figure 4 As shown in the example. In this example, the NRM server (222) evaluates a network resource request as specified in Clause 14.3.3.2 of 3GPP TS 23.434. In this example, the request may include SDP information (e.g., network bandwidth requirements or bandwidth), as described in Table 1.
[0123] At (S520), a media session can be initialized and / or terminated based on the evaluation results at (S510).
[0124] Due to a lack of available network resources, the NRM server (222) may choose to reject the SIP session request. If it is determined at (S510) that the network resource request is rejected, a message indicating the rejection of the network resource request may be sent from the NRM server (222) to the VAL server (221), for example. Thus, the media session (e.g., a SIP media session or a SIP session) is terminated, as per reference. Figure 3 As described.
[0125] The NRM server (222) can determine, for example, by using Clause 14.3.3.2 of 3GPP TS 23.434, whether network resources can be granted from the SIP core. If a network resource grant request is determined at (S510), a message indicating the grant request can be sent from the NRM server (222) to the VAL server (221), for example. One or more requested network resources can be allocated. Therefore, a media session (e.g., a SIP media session or a SIP session) can be established or initialized, similar to reference [reference]. Figure 4 As described.
[0126] The workflow (500) illustrates an example of how a VAL server (221) (e.g., a UAE server) requests a NRM server (222) to complete a session establishment request. In an example, prior to step (S510), the preconditions are met that a VAL client has requested to communicate with the VAL server (221) for VAL service. For example, for a UAV application, a UAV attempts to establish a media session (e.g., a SIP session) between a UAV media payload and a UAV-C or a USS / UTM through a UAV server using a 3GPP core network, and indicates resource requirements of the media session using SIP and SDP.
[0127] As shown in Figure 5 If the NRM server (e.g., the NRM server (222)) determines that there is not enough network resource(s) (e.g., network bandwidth) for the particular SDP description, the media session (e.g., the SIP session) can be terminated immediately. Otherwise, if the NRM server (e.g., the NRM server (222)) determines that there is enough network resource(s) (e.g., network bandwidth) for the particular SDP description and allocates the requested network resource(s) (e.g., network bandwidth), the media session (e.g., the SIP session) can be established.
[0128] The workflow (500) can be adjusted as appropriate. One or more steps in the workflow (500) can be modified and / or omitted. One or more additional steps can be added. Any suitable implementation order can be used.
[0129] Figure 6 A flowchart illustrating a process (600) is shown, in accordance with some embodiments of the present disclosure. The process (600) can be performed by processing circuitry of a VAL server (e.g., the VAL server (121), the VAL server (221)). In an embodiment, the process (600) is performed by processing circuitry of a media session management module of a VAL server (e.g., the VAL server (121), the VAL server (221)). The process (600) can be performed for media session management in wireless communications, such as initialization or establishment of a media session. In an example, the media session is a SIP session. The process (600) can start from (S601) and proceed to (S610).
[0130] At (S610), session description protocol (SDP) information within a session initiation protocol (SIP) payload associated with the media session can be obtained.
[0131] At (S620), for example, a processing circuit of a media session management module of a VAL server (e.g., VAL server (121), VAL server (221)) can send a network resource request including SDP information to a NRM server (e.g., NRM server (222)). The NRM server can be a SEAL server (e.g., SEAL server (122)). The network resource request can request one or more network resources. In an embodiment, the requested one or more network resources include one or more unicast resources, and the process (600) can be for unicast resource management. The requested one or more network resources can include an application type, a bandwidth requirement, a bit rate requirement, a priority, an application identifier, resource sharing information, etc. In an example, the requested one or more network resources include a network bandwidth requirement. In an example, the requested one or more network resources include a bit rate requirement. In an example, the requested one or more network resources are at least one of a network bandwidth requirement and a bit rate requirement. The network bandwidth requirement can indicate a bandwidth (e.g., a maximum bandwidth for an application).
[0132] In an embodiment, the network resource request can be sent using SDP in a SIP payload. In an example, the network resource request includes SDP information (e.g., a network bandwidth requirement), as described in Table 1.
[0133] In an example, the network resource request includes an identification of the VAL server, an identification of a VAL user equipment (UE), and the SDP information.
[0134] At (S630), for example, a processing circuit of the VAL server can receive an evaluation of the network resource request from the NRM server. The evaluation can include one of (i) rejecting the network resource request, or (ii) granting the network resource request.
[0135] In an embodiment, the NRM server evaluates the network resource request to grant or reject the network resource request. After receiving the network resource request, the NRM server can evaluate the network resource request, for example, the demand for network resources, similar to described in (S242). The evaluation can include determining whether to grant or reject the network resource request. In an embodiment, it is determined to reject the network resource request, for example, as shown in (S244). In an embodiment, it is determined to grant the network resource request, for example, as shown in (S246). Figure 3 In an embodiment, it is determined to grant the network resource request, for example, as shown in (S246). In an example, the NRM server evaluates the network resource request as specified in clause 14.3.3.2 of 3GPP TS 23.434. Figure 4
[0136] For example, an NRM server can deny or allow network resource requests based on the availability of one or more network resources. The availability of one or more network resources can be used to determine whether to deny or allow a media session (e.g., a SIP session).
[0137] In this embodiment, the evaluation is based on one of the maximum bandwidth allowed by the media session and the maximum bit rate allowed by the media session.
[0138] In (S640), a media session can be established or terminated in the media session management module of the VAL server based on the received evaluation.
[0139] In this embodiment, in response to a request for permission to access network resources, the requested network resources may be allocated, for example, by an NRM server. A media session may be established based on the allocated network resources.
[0140] In one embodiment, a media session can be terminated in response to a rejection of a network resource request.
[0141] The process (600) can proceed to (S699) and end.
[0142] The process (600) can be adjusted as appropriate. One or more steps in the process (600) can be modified and / or omitted. One or more additional steps can be added. Any suitable implementation order can be used.
[0143] The embodiments in this disclosure can be used individually or in any combination in any order. Furthermore, each of the methods (or embodiments) can be implemented by processing circuitry (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored on a non-volatile computer-readable medium.
[0144] For example, including SDP information in a resource request can be compared with a reference. Figures 2-6 Any of the described embodiments can be combined. The embodiments described in Table 1 can be used in any suitable media session management process for session establishment (or session initialization), session modification, etc.
[0145] The above-mentioned technology can be implemented as computer software through computer-readable instructions and physically stored in one or more computer-readable media.
[0146] The computer software can be encoded using any suitable machine code or computer language, and code including instructions can be created through mechanisms such as assembly, compilation, and linking. These instructions can be executed directly by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc., or executed through decoding, microcode, etc.
[0147] The instructions can be executed on various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, internet of things devices, and the like.
[0148] Figure 7 A computer system (700) is shown suitable for implementing some embodiments of the disclosed subject matter. Figure 7 The components shown for the computer system (700) are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing embodiments of the present disclosure. Neither should the configuration of components be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary embodiment of a computer system (700).
[0149] The computer system (700) can include certain human interface input devices. Such a human interface input device can be a keyboard, a number pad, a mouse, a trackball, a joystick, a touch-screen, a touch-pad, a motion sensor, a camera, a microphone, a scanner, a voice recognition device, a motion recognition device, and / or another suitable action recognition device. These and other input devices are connec ted to or peripheral to the processing module (702) so as to allow a user to provide information to the computer system (700). The user of the computer system (700) can provide input to the computer system (700) via one or more of these input devices.
[0150] The human interface input devices can include one or more of a keyboard (701), a mouse (702), a trackpad (703), a touch screen (710), a data glove (not shown), a joystick (705), a microphone (706), a scanner (707), a camera (708).
[0151] The computer system (700) can also include certain human interface output devices. Such human interface output devices can be a display screen (710), a speaker (709), a haptic feedback device, printer (not shown), and / or another suitable output device. These and other output devices are connec ted to or peripheral to the processing module (702) so as to enable output of information to the computer system (700). The user of the computer system (700) can thus receive output from the computer system (700) via one or more of these output devices.
[0152] Computer system (700) can also include human accessible storage devices and their associated media such as optical disks (720), flash memory (721), floppy diskettes, hard drives, or other memory media (not shown). A user can enter commands and data into the computer system (700) through input device (730). These input devices can include a keyboard, touchscreen, speech recognition device, or any other input device (not shown).
[0153] Those skilled in the art will further appreciate that the term "computer-readable medium" as used herein does not include a transitory medium.
[0154] Computer system (700) can also include a communication interface (754) for wired or wireless communication with one or more other devices, systems, or networks.
[0155] The aforementioned human interface devices, human-accessible storage devices, and network interfaces can be connected to the core (740) of the computer system (700) using various types of communication media (not
[0156] The core (740) can include one or more Central Processing Units (CPU) (741), Graphics Processing Units (GPU) (742), specialized programmable processing units in the form of Field Programmable Gate Arrays (FPGA) (743), hardware accelerators for certain tasks (744), and so forth. These devices, along with Read-only memory (ROM) (745), Random-access memory (RAM) (746), internal mass storage such as internal non-user accessible hard drives, solid state drives, and so forth (747), can be connected through a system bus (748). In some computer systems, the system bus (748) can be accessible in the form of one or more physical plugs to enable extensions of the system bus (748) through additional CPUs, GPU, and so forth. The peripheral devices can be attached either individually or as a card, widget, and so forth, that includes some or all of the peripherals. In an example, a screen (710) can be connected to the graphics adapter (750). Peripherals can be attached either individually or as a card, widget, and so forth, that includes some or all of the peripherals. In an example, a screen (710) can be connected to the graphics adapter (750). The peripheral bus can be a Peripheral Component Interconnect (PCI) bus, a Universal Serial Bus (USB), and so forth.
[0157] The CPU (741), GPU (742), FPGA (743), and accelerators (744) can execute certain instructions that, taken together, can form the aforementioned computer code. The computer code can be stored in ROM (745) or RAM (746). Transitional data for the CPU (741), GPU (742), FPGA (743), and accelerators (744) can be stored in RAM (746), while permanent data can be stored for example, in the internal mass storage (747).
[0158] The computer software can be implemented as computer code that is stored in a computer-readable medium during execution. The computer-readable medium can include non- transitory computer-readable media, which excludes wire, cable, fiber, and wireless transmissions. Storage media can include volatile and non-volatile, removable and non-removable media implemented in a method or technology for storage and / or transfer of information such as computer software. The storage media can include computer storage media and communication media. The computer storage media can include, but is not limited to, volatile and non-volatile, removable and non-removable media implemented in a method or technology such as, but not limited to, RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, cassette, tape, magnetic or optical media, volatile or non-volatile memory devices, and the like. The computer storage media can also include, but is not limited to, devices that allow storage and / or transfer of data such as, but not limited to, bar code, paper, punch cards, cassette, tape, magnetic or optical media, volatile or non-volatile memory devices, and the like. The communication media can include computer software in a signals, electromagnetic, optical, and the like, that are computer readable by a computer. A computer readable medium can include one or both of a computer software program that causes a computer to implement a process, or a computer self- implementing a process where the computer is equipped with appropriate programs of instructions. The computer software can be structured in any form that allows a computer to read the computer software.
[0159] By way of example and not limitation, a computer system having an architecture (700), particularly a core (740), can provide functionality as a processor (including a CPU, GPU, FPGA, accelerator, etc.) to execute software contained in one or more tangible computer-readable media. Such computer-readable media can be media associated with the aforementioned user-accessible mass storage, as well as specific memory of the core (740) that is non-volatile, such as internal mass storage (747) or ROM (745). Software implementing various embodiments of this disclosure can be stored in such a device and executed by the core (740). Depending on specific needs, the computer-readable medium may include one or more storage devices or chips. The software can cause the core (740), particularly the processor therein (including a CPU, GPU, FPGA, etc.), to execute specific processes or specific portions of specific processes described herein, including defining data structures stored in RAM (746) and modifying such data structures according to software-defined processes. Alternatively or as an alternative, the computer system may provide logic hardwired or otherwise included in circuitry (e.g., an accelerator (744)) that may replace or operate with the software to perform the specific process or a specific portion of the specific process described herein. References to software may include logic, and vice versa, where appropriate. References to computer-readable media may include, where appropriate, circuitry storing the execution of software (such as an integrated circuit (IC)), circuitry containing execution logic, or both. This disclosure includes any suitable combination of hardware and software.
[0160] While this disclosure has described several exemplary embodiments, various modifications, arrangements, and equivalent substitutions of the embodiments are within the scope of this disclosure. Therefore, it should be understood that those skilled in the art can design various systems and methods that, while not explicitly shown or described herein, embody the principles of this disclosure and are thus within its spirit and scope.
Claims
1. A method for media session management in wireless communication, characterized in that, include: The vertical application layer VAL server obtains Session Description Protocol (SDP) information within the Session Initiation Protocol (SIP) payload associated with the media session between the VAL server and the VAL client, wherein the SDP information includes the maximum bandwidth and maximum bit rate allowed for the media session. The media session management module of the VAL server sends a network resource request, including the SDP information, to the network resource management NRM server. The NRM server is a service enablement architecture layer SEAL server. The network resource request requests network resources, wherein the network resources are at least one of the maximum bandwidth and maximum bit rate allowed by the media session. The VAL server receives permission or rejection for the network resource request from the NRM server, wherein the permission or rejection is based on one of the maximum bandwidth and maximum bit rate allowed by the media session; and the network resource request is determined to be incorrect when it does not include SDP information containing the maximum bandwidth and maximum bit rate allowed by the media session. Based on the received permission or denial, the media session is established or terminated in the media session management module of the VAL server.
2. The method according to claim 1, characterized in that, Further includes: In response to granting the network resource request, The NRM server allocates the requested network resources; as well as The media session is established based on the allocated network resources.
3. The method according to claim 1, characterized in that, The media session is a SIP session.
4. The method according to claim 1, characterized in that, The network resource request further includes the identifier of the VAL server and the identifier of the VAL user equipment (UE).
5. An apparatus for media session management in wireless communication, characterized in that, include: The acquisition module is used to acquire Session Description Protocol (SDP) information within the Session Initiation Protocol (SIP) payload associated with the media session between the vertical application layer VAL server and VAL client, wherein the SDP information includes the maximum bandwidth and maximum bit rate allowed by the media session; The sending module is used to send a network resource request including the SDP information to the Network Resource Management (NRM) server, wherein the NRM server is a Service Enablement Architecture (SEAL) server, and the network resource request requests network resources, wherein the network resources are at least one of the maximum bandwidth and maximum bit rate allowed by the media session. A receiving module is configured to receive, from the NRM server, an approval or rejection of the network resource request, wherein the approval or rejection is based on one of the maximum bandwidth and maximum bit rate allowed by the media session, and the network resource request is determined to be incorrect when it does not include SDP information containing the maximum bandwidth and maximum bit rate allowed by the media session; and The media session processing module is used to establish or terminate the media session in the media session management module of the VAL server based on the received permission or denial.
6. The apparatus according to claim 5, characterized in that, In response to granting the network resource request, The NRM server allocates the requested network resources; and The media session processing module establishes the media session based on the allocated network resources.
7. The apparatus according to claim 5, characterized in that, The media session is a SIP session.
8. The apparatus according to claim 5, characterized in that, The network resource request further includes the identifier of the VAL server and the identifier of the VAL user equipment (UE).
9. A non-volatile computer-readable medium, characterized in that, Used to store instructions that, when executed by a processor, cause the processor to perform the method described in any one of claims 1-4.
Citation Information
Patent Citations
Content receiving device and method
US20090064218A1