Enabling Vertical Application Tier Servers for Peer-to-Peer Media Parameter Negotiation

Abstract

A method, computer program, and computer system for enabling peer-to-peer media streaming using a Service Enabler Architecture Layer (SEAL) can be executed by one or more processors. The method can include receiving, by a Vertical Application Layer (VAL) server, a request for media session negotiation between one or more client devices, and retrieving, by the Vertical Application Layer (VAL) server, transport layer information associated with each of the one or more client devices using network address translation traversal. The method can further include sending, by the Vertical Application Layer (VAL) server, agreed-upon Session Description Protocol (SDP) parameters based on the transport layer information, where the agreed-upon Session Description Protocol (SDP) parameters are used to establish the peer-to-peer media streaming session.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 219,306, filed July 7, 2021, and U.S. Patent Application No. 17 / 858,323, filed July 6, 2022, in the U.S. Patent and Trademark Office, each of which is incorporated herein in its entirety.

[0002] The present disclosure relates to enabling peer-to-peer media parameter negotiation and communication. More particularly, the present disclosure relates to the design and operation of a Vertical Service Enabler Architecture Layer (SEAL) for enabling Vertical Application Layer (VAL) servers for peer-to-peer (P2P) media parameter negotiation. [Background technology]

[0003] The Service Enabler Architecture Layer (SEAL) can be used over 3GPP wireless networks to support vertical (VAL) applications (e.g., UAV, V2X applications). The SEAL functional architecture can include common application plane entities and signaling plane entities. A set of common services (e.g., group management, configuration management, location management) specified in this document can be shared across vertical applications.

[0004] As peer-to-peer (P2P) media streaming technology becomes a promising media streaming method, a method is needed to reduce the cost and communication delay of centralized media servers. Summary of the Invention [Means for solving the problem]

[0005] Embodiments relate to methods, systems, and computer-readable media for enabling peer-to-peer media streaming using a Service Enabler Architecture Layer (SEAL). According to one aspect, a method for enabling peer-to-peer media streaming using a Service Enabler Architecture Layer (SEAL) can be provided. The method can be executed by one or more processors, and can include receiving, by a Vertical Application Layer (VAL) server, a request for media session negotiation between one or more client devices, and retrieving, by the Vertical Application Layer (VAL) server, transport layer information associated with each of the one or more client devices using network address translation traversal. The method can further include sending, by the Vertical Application Layer (VAL) server, agreed-upon Session Description Protocol (SDP) parameters based on the transport layer information, the agreed-upon Session Description Protocol (SDP) parameters being used to establish the peer-to-peer media streaming session.

[0006] According to another aspect, an apparatus can be provided for enabling peer-to-peer media streaming using a Service Enabler Architecture Layer (SEAL). The apparatus includes at least one memory configured to store computer program code, and at least one processor configured to access the at least one memory and operate as instructed by the computer program code. The program code can include a request receiving code configured to cause the at least one processor to receive, by a Vertical Application Layer (VAL) server, a request for media session negotiation between one or more client devices, a retrieval code configured to cause the at least one processor to retrieve, by the Vertical Application Layer (VAL) server, transport layer information associated with each of the one or more client devices using network address translation traversal, and a sending code configured to cause the at least one processor to send, by the Vertical Application Layer (VAL) server, agreed-upon Session Description Protocol (SDP) parameters based on the transport layer information, the agreed-upon Session Description Protocol (SDP) parameters being used to establish the peer-to-peer media streaming session.

[0007] According to yet another aspect, a non-transitory computer-readable medium can be provided that stores instructions for enabling peer-to-peer media streaming using a Service Enabler Architecture Layer (SEAL). The instructions can include one or more instructions configured, when executed by one or more processors, to cause the one or more processors to receive, by a Vertical Application Layer (VAL) server, a request for media session negotiation between one or more client devices, to cause, by the Vertical Application Layer (VAL) server, to retrieve, by using network address translation traversal, transport layer information associated with each of the one or more client devices, and to send, by the Vertical Application Layer (VAL) server, agreed-upon Session Description Protocol (SDP) parameters based on the transport layer information, where the agreed-upon Session Description Protocol (SDP) parameters are used to establish the peer-to-peer media streaming session.

[0008] These and other objects, features and advantages will become apparent from the following detailed description of illustrative embodiments, which is to be read in connection with the accompanying drawings, in which various features of the drawings are not to scale because the drawings are for clarity in conjunction with the detailed description to facilitate understanding by those skilled in the art. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 illustrates an example functional architecture of a Vertical Service Enabler Architecture Layer (SEAL). [Diagram 2] FIG. 1 illustrates an example workflow for enabling peer-to-peer media streaming using the Service Enabler Architecture Layer (SEAL). [Diagram 3] FIG. 1 illustrates an example flow chart for enabling peer-to-peer media streaming using the Service Enabler Architecture Layer (SEAL). [Figure 4] FIG. 1 illustrates an exemplary computer system for enabling peer-to-peer media streaming using a Service Enabler Architecture Layer (SEAL). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Although detailed embodiments of the claimed structures and methods are disclosed herein, it can be understood that the disclosed embodiments are merely exemplary of the claimed structures and methods, which may be embodied in various forms. However, these structures and methods may be embodied in many different forms and should not be construed as being limited to the exemplary embodiments described herein. On the contrary, these exemplary embodiments are provided so that this disclosure will be thorough and complete, and will fully convey its scope to those skilled in the art. In this description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments.

[0011] Aspects are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer-readable media according to various embodiments. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0012] 1 illustrates an exemplary vertical service enabler architecture layer (SEAL) functional architecture 100 for enabling peer-to-peer media streaming. As shown in FIG. 1, the SEAL functional architecture 100 can include a vertical application layer (VAL) client 105, a VAL server 110, a SEAL server 130, a SEAL client 125, one or more VAL-UU reference points 115, one or more SEAL-UU reference points 135, and a user equipment 120.

[0013] According to one embodiment of the present disclosure, the VAL Client 105 can communicate with the VAL Server 110 via one or more VAL-UU reference points 115. The VAL-UU 115 can support both unicast and multicast delivery modes.

[0014] The SEAL functional entities on the user equipment 120 and the SEAL server 130 are grouped into SEAL clients 125 and SEAL servers 130, respectively. The SEAL functions consist of a common set of services (e.g., group management, location management) and reference points. The SEAL functions can provide their services to the Vertical Application Layer (VAL).

[0015] The SEAL client 125 can communicate with the SEAL server 130 via one or more of the SEAL-UU 135 reference points. One or more of the SEAL-UU 135 can support both unicast and multicast delivery modes. The SEAL client 125 can provide service enabler layer support functionality to the VAL client 105 via one or more SEAL-C reference points 140. The VAL server 110 can communicate with the SEAL server 130 via one or more SEAL-S reference points 145. The SEAL server 130 can communicate with the underlying 3GPP network system using the respective 3GPP interfaces specified by the 3GPP network system.

[0016] According to an embodiment, a specific SEAL client and a specific SEAL server can be described in the respective on-network functional model of each SEAL service, along with their specific SEAL-UU reference points and specific network interfaces of the 3GPP network system used.

[0017] The VAL client 105 can provide client-side functionality corresponding to a vertical application (e.g., UAV, V2X client). The VAL client can support interactions with the SEAL client 125. The VAL server 110 can provide server-side functionality corresponding to a vertical application (e.g., UAV, V2X application server).

[0018] The SEAL client 125 can provide client-side functionality corresponding to a particular SEAL service. The SEAL client 125 can support interactions with the VAL client 105. The SEAL client can also support interactions between one or more user devices with a corresponding SEAL client.

[0019] The SEAL server 130 may provide server-side functionality corresponding to a particular SEAL service. The SEAL server 130 may support interactions with the VAL server 110.

[0020] According to an embodiment, the SEAL functional architecture 100 allows for common capabilities to support mission-critical and other vertical applications.

[0021] In some embodiments, the SEAL functional architecture 100 can provide network resource management, and a network resource management client, i.e., SEAL client 12, can function as a VAL client 105 for managing network resources. The network resource management client can interact with a network resource management server, i.e., SEAL server 130. The network resource management server can enable and permit management of 3GPP system network resources (e.g., unicast, multicast) to support the VAL client 105. Interactions related to network resource management functions between the network resource management client (SEAL client 125) and the network resource management server (SEAL server 130) can be supported by one or more NRM-UU reference points 135. In some embodiments, interactions related to network resource management functions between the VAL server 110 and the network resource management server (i.e., SEAL server 130) are supported by one or more NRM-S reference points 145.

[0022] As an example, the SDP used in the SIP package can carry important information about media parameters and can be sent from the VAL server 110 to the network resource management using NRM-S. v=0 o=Client1 2398026505 2307593197 IN IP4 100.200.130.140 s=Client1 Audio Session b=AS:64 b=RS:800 b=RR:2400 c=IN IP4 10.11.12.13 t=0 0 m=audio 15010 RTP / AVP 0 101 a=rtpmap:0 PCMU / 8000 a=rtpmap:101 telephone-event / 8000 a=sendrecv

[0023] According to some embodiments, peer-to-peer (P2P) media streaming technologies, such as WebRTC, are becoming a promising media streaming method. However, the costs associated with centralized media servers need to be reduced, and so does the communication latency. Enabling P2P media parameter signaling using SEALs with media payloads in the Vertical Application Layer (VAL) (e.g., UASAPP and V2X) is an essential step for establishing a media session, such as using the Session Initiation Protocol (SIP).

[0024] According to an embodiment, a key way to enable media session communication may be to use Network Address Translation (NAT) traversal techniques. As an example, techniques such as Interactive Connectivity Establishment (ICE), session traversal utilities for NAT (STUN), and traversal using relays around NAT (TURN) may be used by the server to identify the IP addresses of all peers. The Session Description Protocol (SDP) is one protocol that may be used for media session parameter negotiation.

[0025] Embodiments of the present disclosure relate to enabling a VAL server for P2P media parameter negotiation using existing SEAL signaling architecture, such as NAT traversal provided by NRM-S.

[0026] 2 illustrates an example workflow 200 for enabling peer-to-peer media streaming using the Service Enabler Architecture Layer (SEAL). As shown in FIG. 2, the workflow 200 can include a VAL Client 1 205, a VAL Client 2 220, a VAL Server 210, a Network Resource Management (NRM) Server 215, and a number of operations 250-260.

[0027] According to an embodiment, the workflow 200 can disclose specifying media session parameters negotiated between a VAL client and a VAL server and transmitted by multiple VAL clients and carried in SDP. The request can be transmitted from a VAL client and can include a VAL user identity, a user equipment ID, and an SDP offer. The VAL server can utilize an NRM server for media session signaling and can use NAT traversal techniques to retrieve transport layer information related to the VAL client. The VAL server can return the agreed SDP parameters for all VAL clients. The VAL client can then use the agreed SDP parameters to establish a peer-to-peer media streaming session.

[0028] In operations 250-252, the VAL client may send a media session parameter negotiation request to the VAL server. As an example, the VAL client 1 205 and the VAL client 2 220 may send a media session parameter negotiation request to the VAL server 210. In some embodiments, the VAL server 210 may pull or receive the request for media session parameter negotiation from the VAL client 1 205 and the VAL client 2 220. In some embodiments, the media session parameter negotiation request includes a requestor identity, a VAL user ID, a VAL user equipment ID, and / or an SDP offer, as shown in Table 1.

[0029] [Table 1]

[0030] In operation 255, the VAL server can use a network resource management (NRM) server to determine transport layer information of the VAL client. The transport layer information can include the IP and port number of each connected peer (e.g., VAL client) specified by the SDP. The NRM server can utilize NAT traversal capabilities and return the transport layer information of each peer to the VAL server. As an example, the VAL server 210 can use NAT traversal capabilities to retrieve the transport layer information of each VAL client 1 205 and VAL client 2 220 from the NRM server 215. In some embodiments, the VAL server can consolidate the transport layer information from the NRM server and send the agreed SDP parameters back to each peer. The SDP parameters or SDP feedback can include parameters as disclosed in Table 2.

[0031] [Table 2]

[0032] In operations 256-258, the retrieved transport layer information and / or the agreed upon SDP parameters may be sent to each requesting VAL client. As an example, the parameters may be sent from the VAL server 210 to VAL client 1 205 and VAL client 2 220, as disclosed below. As an example, the returned ICE candidates list the IP addresses of other peers.

[0033] [Table 3]

[0034] Each peer may send transport layer information to establish a P2P media streaming session in operation 260. As an example, in operation 260, VAL client 1 205 and VAL client 2 220 may establish a P2P media streaming session using the transport layer information.

[0035] Operations 250-252 and 256-258 may be performed in any order, and this disclosure discloses but is not limited to the order or operations 250-260.

[0036] According to one embodiment, P2P media streaming technology (e.g., WebRTC) can be used. WebRTC is a collection of communication protocols, and utilizing webRTC can include four major steps: signaling (e.g., using SDP), connecting (e.g., using NAT traversal with STUN / TURN servers or ICE agents for each peer), securing (e.g., DTLS, SRTP), and communicating (e.g., using RTP for media data or SCTP).

[0037] P2P media streaming technologies can use an offer / answer model. The model can include an agent configured to make an "offer" to initiate a call, and the other agent "answers" if it is willing to accept what is offered, giving the answerer the opportunity to reject the offer (e.g., rejecting the offer because a codec is not supported in the media description). The offer / answer model of some P2P media streaming technologies can enable two peers to understand what formats they intend to exchange. As an example, a transceiver is a WebRTC specific concept that can be found in its application programming interface (API). A transceiver can expose a "media description" to the JavaScript API. Each media description can be a transceiver. Thus, each time a transceiver is created, a new media description can be added to the local session description. Each media description in WebRTC can have a direction attribute. The direction attribute may allow a WebRTC agent to declare, "I'm going to send this codec, but I'm not going to accept anything."

[0038] According to an embodiment, WebRTC signaling using SDP may include the following parameters, as disclosed in Table 3:

[0039] [Table 4]

[0040] For P2P media communication, each peer may need to know the capacity and capabilities of each peer's offering. The capacity and capabilities may include CODEC support and bandwidth. Since each peer may be behind a firewall, to establish a P2P media streaming session, each peer may also need to know each peer's public IP address. According to an embodiment, the VAL server may be enabled to perform P2P media negotiation by utilizing the SEAL NRM server.

[0041] FIG. 3 illustrates an example flow chart 300 for enabling peer-to-peer media streaming using the Service Enabler Architecture Layer (SEAL).

[0042] The VAL server may receive a request for a media session negotiation between one or more client devices, as seen in operation 305. As an example, the VAL server 210 may receive a request from VAL client 1 205 and VAL client 2 220.

[0043] As seen in operation 310, the VAL server can use network address translation traversal to retrieve transport layer information associated with each of the one or more client devices. The VAL server can retrieve transport layer information associated with each of the one or more client devices from a network resource management server. As an example, the VAL server 210 can use network address translation traversal from the NRM server 215 to retrieve transport layer information associated with each of the one or more client devices.

[0044] In some embodiments, the transport layer information may include one or more of a respective IP address and a respective port number associated with each of the one or more client devices. In some embodiments, the VAL server may retrieve agreed-upon Session Description Protocol (SDP) parameters. The agreed-upon Session Description Protocol (SDP) parameters may include one or more of an accepted codec, an interactive connection establishment candidate, a media type, an available codec support, and a bandwidth. In some embodiments, the agreed-upon Session Description Protocol (SDP) parameters may further include one or more of a plurality of synchronization sources, and a parameter required by a management protocol.

[0045] As seen in operation 315, the VAL server may aggregate the retrieved transport layer information associated with each of the one or more client devices. In some embodiments, the VAL server may aggregate the retrieved transport layer information and the agreed-upon SDP parameters associated with each of the one or more client devices. In some embodiments, the VAL server may aggregate the information before sending the agreed-upon Session Description Protocol (SDP) parameters.

[0046] As seen in operation 320, the VAL server can send agreed-upon Session Description Protocol (SDP) parameters based on the transport layer information, where the agreed-upon Session Description Protocol (SDP) parameters are used to establish a peer-to-peer media streaming session. As an example, the VAL server 210 can send agreed-upon Session Description Protocol (SDP) parameters that the VAL client 1 205 and the VAL client 2 220 can use to establish a P2P media streaming session.

[0047] As seen in operation 325, the one or more client devices may establish a peer-to-peer media streaming session based on the transport layer information associated with each of the one or more client devices and the agreed-upon Session Description Protocol (SDP) parameters. As an example, VAL Client 1 205 and VAL Client 2 220 may establish a P2P media streaming session between themselves.

[0048] The components illustrated in Figure 4 for computer system 400 may be used to implement any of the devices disclosed in Figures 1-3 and 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 the embodiments of the present disclosure. Neither should the arrangement of components be interpreted as having any dependency or requirement regarding any one or combination of components illustrated in the exemplary embodiment of computer system 400.

[0049] The computer system 400 may include certain human interface input devices. Such human interface input devices may be responsive to input by one or more human users, for example, via tactile input (e.g., keystrokes, swipes, data glove movements), audio input (e.g., voice, clapping), visual input (e.g., gestures), olfactory input (not shown). Human interface devices may also be used to capture certain media not necessarily directly associated with conscious human input, such as audio (e.g., voice, music, ambient sounds, etc.), images (e.g., scanned images, photographic images obtained from a still camera, etc.), and video (e.g., two-dimensional video, three-dimensional video including stereoscopic video, etc.).

[0050] The input human interface devices may include one or more of a keyboard 401, a mouse 402, a trackpad 403, a touch screen 410, a data glove (not shown), a joystick 405, a microphone 406, a scanner 407, and a camera 408 (only one of each is shown).

[0051] The computer system 400 may also include certain human interface output devices. Such human interface output devices may stimulate one or more of the human user's senses, for example, through haptic output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touch screen 410, data gloves (not shown), or joystick 405, although there may also be haptic feedback devices that do not function as input devices), audio output devices (such as speakers 409, headphones (not shown)), visual output devices (such as screens 410, including CRT screens, LCD screens, plasma screens, OLED screens, each with or without touch screen input capabilities, each with or without haptic feedback capabilities, some of which may be capable of outputting two-dimensional visual output or three-dimensional or higher output via means such as stereographic output, virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), and printers (not shown).

[0052] The computer system 400 may also include human accessible storage devices and associated media for storage devices such as optical media including CD / DVD ROM / RW 420 with CD / DVD or similar media 421, thumb drives 422, removable hard drives or solid state drives 423, legacy magnetic media such as tapes and floppy disks (not shown), dedicated ROM / ASIC / PLD based devices (not shown) such as security dongles, etc.

[0053] Additionally, those skilled in the art should understand that the term "computer-readable medium" as used in connection with the subject matter of this disclosure does not encompass transmission media, carrier waves, or other transitory signals.

[0054] The computer system 400 may also include interfaces to one or more communication networks. The networks may be, for example, wireless, wired, optical. The networks may further be local, wide area, metropolitan, vehicular and industrial, real-time, delay tolerant, etc. Examples of networks include local area networks such as Ethernet, wireless LAN, cellular networks including GSM, 3G, 5G, 5G, LTE, etc., TV wired or wireless wide area digital networks including cable TV, satellite TV, and terrestrial broadcast TV, vehicular and industrial including CANBus, etc. Certain networks typically require an external network interface adapter attached to a particular general-purpose data port (e.g., a USB port or peripheral bus (449) of computer system 400, while other networks are typically integrated into the core of computer system 400 by attachment to a system bus described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system). Using any of these networks, computer system 400 can communicate with other entities. Such communications may be unidirectional receive only (e.g., broadcast TV), unidirectional transmit only (e.g., CANbus to certain CANbus devices), or bidirectional, for example, with other computer systems using local or wide area digital networks. Specific protocols and protocol stacks may be used with each of those networks and network interfaces described above.

[0055] The aforementioned human interface devices, human accessible storage devices, and network interfaces may be attached to the core 440 of the computer system 400.

[0056] The core 440 may include one or more central processing units (CPUs) 441, graphics processing units (GPUs) 442, dedicated programmable processing units in the form of field programmable gate areas (FPGAs) 443, and hardware accelerators for specific tasks 444, etc. These devices may be connected via a system bus 448, along with read only memory (ROM) 445, random access memory 446, internal mass storage such as internal hard drives that are not accessible to the user, SSDs, etc. 447. In some computer systems, the system bus 448 may be accessible in the form of one or more physical plugs to allow expansion with additional CPUs and GPUs, etc. Peripheral devices may be attached directly to the core's system bus 448 or via a peripheral bus 449. Peripheral bus architectures include PCI, USB, etc.

[0057] The CPU 441, GPU 442, FPGA 443, and accelerator 444 may execute certain instructions that, in combination, may constitute the aforementioned computer code. That computer code may be stored in ROM 445 or RAM 446. Persistent data may be stored, for example, in internal mass storage 447, while transitory data may also be stored in RAM 446. Rapid storage and retrieval from any of the memory devices may be made operable using cache memories that may be closely associated with one or more of the CPU 441, GPU 442, mass storage 447, ROM 445, RAM 446, etc.

[0058] The computer-readable medium can bear computer code for performing various computer-implemented operations. The medium and computer code may be those specially designed and constructed for the purposes of the present disclosure, or they may be of the kind well known and available to those skilled in the computer software arts.

[0059] As an example, and not by way of limitation, the architecture, particularly the computer system 400 having the core 440, can provide functionality as a result of processors (including CPUs, GPUs, FPGAs, accelerators, etc.) executing software embodied in one or more tangible computer-readable media. Such computer-readable media may be user-accessible mass storage as introduced above, and media associated with the specific storage of the core 440, of a non-transitory nature, such as the mass storage 447 internal to the core or ROM 445. Software implementing various embodiments of the present disclosure can be stored in such devices and executed by the core 440. The computer-readable media may include one or more memory devices or chips, depending on the particular needs. The software can cause the core 440, particularly the processors therein (including CPUs, GPUs, FPGAs, etc.) to perform certain processes or certain parts of certain processes described herein, including defining data structures stored in the RAM 446 and modifying such data structures according to the processes defined by the software. Additionally or alternatively, a computer system may provide functionality as a result of logic hardwired or otherwise embodied in circuitry (e.g., accelerator 444), which may operate in place of or in conjunction with software to perform particular processes or particular portions of particular processes described herein. Where appropriate, references to software may encompass logic and vice versa. Where appropriate, references to computer-readable media may encompass circuitry (such as integrated circuits (ICs)) that stores software for execution, circuitry that embodies logic for execution, or both. The present disclosure encompasses any suitable combination of hardware and software.

[0060] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of integration of technical details. The computer-readable media may include a computer-readable non-transitory storage medium having computer-readable program instructions for causing a processor to perform operations.

[0061] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves with instructions recorded on them, and any suitable combination of the above. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over electrical wires.

[0062] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium into each computing / processing device, or can be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0063] The computer readable program code / instructions for performing the operations may be either assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk or C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or a connection may be made to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), can execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuit to perform an aspect or operation.

[0064] These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to generate a machine such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram blocks. These computer-readable program instructions may also be stored on a computer-readable storage medium that may direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having stored instructions includes an article of manufacture including instructions that implement aspects of the functions / acts specified in the flowchart and / or block diagram blocks.

[0065] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device such that a series of operational steps are executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process such that the instructions, executed on the computer, other programmable apparatus, or other device, implement the functions / acts specified in the flowchart and / or block diagram blocks.

[0066] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or part of an instruction that includes one or more executable instructions for implementing a specified logical function. The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to those shown in the figures. In some alternative implementations, the functions described in the blocks may be performed in a different order than described in the figures. For example, two blocks shown in succession may in fact be executed simultaneously or substantially simultaneously, or the blocks may be executed in reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, as well as combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or realizes a combination of dedicated hardware and computer instructions.

[0067] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0068] No element, act, or instruction used herein should be construed as critical or essential unless expressly described as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and can be used interchangeably with "one or more." Additionally, the term "set" as used herein includes one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and can be used interchangeably with "one or more." When only one item is intended, the term "one" or similar words are used. Also, as used herein, terms such as "has," "have," "having," and the like are intended to be open-ended terms. Additionally, the phrase "based on" is intended to mean "based at least in part on," unless otherwise specified.

[0069] The description of various aspects and embodiments is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Although combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features can be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terms used in this specification have been selected to best explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the marketplace, or to enable those skilled in the art to understand the embodiments disclosed herein. [Explanation of symbols]

[0070] 100 SEAL Functional Architecture 105 VAL Client 110 VAL Server 115 VAL-UU reference point 120 User Equipment 125 SEAL Client 130 SEAL Server 135 SEAL-UU reference point, NRM-UU reference point 140 SEAL-C Reference Point 145 SEAL-S reference point, NRM-S reference point 200 Workflow 205 VAL Client 1 210 VAL Server 215 Network Resource Management (NRM) Server 220 VAL Client 2 250 operations 252 operation 255 operation 256 operation 258 operation 260 operations 300 Flowchart 305 operation 310 operation 315 operation 320 operation 325 operation 400 Computer Systems 401 Keyboard 402 Mouse 403 Trackpad 405 Joystick 406 Mike 407 Scanner 408 Camera 409 Speaker 410 Touch Screen 420 CD / DVD ROM / RW 421 Media 422 Thumb Drive 423 Removable Hard Drive or Solid State Drive 440 cores 441 Central Processing Unit (CPU) 442 Graphics Processing Unit (GPU) 443 Field Programmable Gate Area (FPGA) 444 Hardware Accelerator 445 Read-Only Memory (ROM) 446 Random Access Memory, RAM 447 Internal Mass Storage 448 System Bus 449 Surrounding Bus

Claims

1. 1. A method for enabling peer-to-peer media streaming using a Service Enabler Architecture Layer (SEAL), the method being executed by one or more processors, the method comprising: receiving, by a vertical application layer (VAL) server, a request for media session negotiation between a plurality of client devices; obtaining, by the Vertical Application Layer (VAL) server, transport layer information associated with each of the plurality of client devices from a Network Resource Management (NRM) server using network address translation traversal; transmitting, by the Vertical Application Layer (VAL) server, Session Description Protocol (SDP) parameters acceptable to at least two of the plurality of client devices based on the transport layer information, to the plurality of client devices, the acceptable Session Description Protocol (SDP) parameters being used to establish a peer-to-peer media streaming session; A method comprising:

2. 2. The method of claim 1, wherein the request includes at least one of a requestor identifier, identification information associated with a VAL user, a user equipment identifier, and a Session Description Protocol (SDP) offer.

3. The method of claim 1 , wherein the transport layer information includes one or more of a respective IP address and a respective port number associated with each of the plurality of client devices.

4. 2. The method of claim 1, further comprising: consolidating, by the Vertical Application Layer (VAL) server, the transport layer information associated with each of the plurality of client devices prior to sending the acceptable Session Description Protocol (SDP) parameters.

5. 2. The method of claim 1, wherein the acceptable Session Description Protocol (SDP) parameters include one or more of accepted codecs, interactive connection establishment candidates, media types, available codec support, and bandwidth.

6. 6. The method of claim 5, wherein the acceptable Session Description Protocol (SDP) parameters further include one or more of a plurality of synchronization sources and parameters required by a management protocol.

7. The method includes the step of establishing, by the plurality of client devices, the peer-to-peer media streaming session based on the transport layer information associated with each of the plurality of client devices and the acceptable Session Description Protocol (SDP) parameters. The method of claim 1, further comprising:

8. 1. An apparatus for enabling peer-to-peer media streaming using a Service Enabler Architecture Layer (SEAL), comprising: at least one memory configured to store computer program code; at least one processor configured to access said at least one memory and to operate as instructed by said computer program code; said computer program code comprising: a request receiving code configured to cause at least one processor to receive, by a vertical application layer (VAL) server, a request for media session negotiation between a plurality of client devices; a retrieval code configured to cause at least one processor to retrieve, by the Vertical Application Layer (VAL) server, transport layer information associated with each of the plurality of client devices from a Network Resource Management (NRM) server using a Network Address Translation traversal; a transmitting code configured to cause at least one processor to transmit, by the Vertical Application Layer (VAL) server, Session Description Protocol (SDP) parameters acceptable by at least two of the plurality of client devices based on the transport layer information, to the plurality of client devices, the acceptable Session Description Protocol (SDP) parameters being used to establish a peer-to-peer media streaming session; 13. An apparatus comprising:

9. 10. The apparatus of claim 8, wherein the request includes at least one of a requestor identifier, identification information associated with a VAL user, a user equipment identifier, and a Session Description Protocol (SDP) offer.

10. 9. The apparatus of claim 8, wherein the transport layer information includes one or more of a respective IP address and a respective port number associated with each of the plurality of client devices.

11. 9. The apparatus of claim 8, wherein the computer program code is configured to cause the at least one processor to consolidate, by the Vertical Application Layer (VAL) Server, the transport layer information associated with each of the plurality of client devices prior to sending the acceptable Session Description Protocol (SDP) parameters.

12. 9. The apparatus of claim 8, wherein the acceptable Session Description Protocol (SDP) parameters include one or more of accepted codecs, interactive connection establishment candidates, media types, available codec support, and bandwidth.

13. 13. The apparatus of claim 12, wherein the acceptable Session Description Protocol (SDP) parameters further include one or more of a plurality of synchronization sources and parameters required by a management protocol.

14. 10. The apparatus of claim 8, wherein the computer program code is configured to cause at least one processor to establish, by the plurality of client devices, the peer-to-peer media streaming session based on the transport layer information associated with each of the plurality of client devices and the acceptable Session Description Protocol (SDP) parameters.

15. A program for causing at least one processor to carry out the method according to any one of claims 1 to 7.

Images