Patent Description:
To meet the demand for wireless data traffic having increased since deployment of <NUM>th generation (<NUM>) communication systems, efforts have been made to develop an improved <NUM>th generation (<NUM>) or pre-<NUM> communication system. Therefore, the <NUM> or pre-<NUM> communication system is also called a 'Beyond <NUM> Network' or a 'Post Long Term Evolution (LTE) System'.

In the <NUM> system, Hybrid frequency shift keying (FSK) and quadrature amplitude modulation (FQAM) and sliding window superposition coding (SWSC) as an advanced coding modulation (ACM), and filter bank multi carrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) as an advanced access technology have been developed.

A network operator (e.g., <NUM>, <NUM>/LTE, <NUM> operator) provides connectivity services to end users. As part of the end-to-end connectivity, the end user clients are usually connected to the operator core network using radio access networks such as E-UTRAN, <NUM> NR etc. The services that the end user clients can access could be the services provided by the network operator itself or the services provided by <NUM>rd party service providers that use operator's network to deliver their services to interested users. One of the services that is slowly gaining traction is the uplink service. In this service, a user behind a radio access network (such as <NUM> NR, WiFi), can register or subscribe to an uplink service which can host content from the end users and distribute the content later to interested users. This uplink service can either be managed by the network operator or by an external <NUM>rd party service provider on behalf of the network operator. Network operators or <NUM>rd party providers can provision uplink services with different characteristics (so network operators or <NUM>rd party providers support a varied set of uplink service requirements). It is highly possible that these uplink services are provisioned dynamically, in which case, there needs to be methods defined for discovery of these uplink services by the UE so the user can use the uplink service of his choice. In addition, once the uplink services are discovered, an access mechanism is needed for end user clients to use to connect to the chosen uplink service and upload content for later distribution.

Embodiments of the present disclosure provide an improved efficiency of distributing media contents from a user to another user using uplink services.

Various embodiments of the present disclosure provide a discovery and access procedures that is more effective.

The following documents and standards are related to the invention.

<NPL>" <NPL>" <NPL>" <NPL>" "Study of ISO/IEC CD <NUM>-<NUM> MPEG Media Transport;" <NPL>" <NPL>" <NPL>" <NPL>" <NPL>" and <NPL>".

<NPL> discloses a local V2X service discovery with the indication of the location of a service discovery server.

As shown in <FIG>, the wireless network includes an evolved NodeB (eNB) <NUM>, an eNB <NUM>, and an eNB <NUM>. The eNB <NUM> communicates with the eNB <NUM> and the eNB <NUM>. The eNB <NUM> also communicates with at least one network <NUM>, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network.

The eNB <NUM> provides wireless broadband access to the network <NUM> for a first plurality of user equipments (UEs) within a coverage area <NUM> of the eNB <NUM>. The first plurality of UEs includes a UE <NUM>, which may be located in a small business (SB); a UE <NUM>, which may be located in an enterprise (E); a UE <NUM>, which may be located in a WiFi hotspot (HS); a UE <NUM>, which may be located in a first residence (R); a UE <NUM>, which may be located in a second residence (R); and a UE <NUM>, which may be a mobile device (M), such as a cell phone, a wireless laptop, a wireless PDA, or the like. The eNB <NUM> provides wireless broadband access to the network <NUM> for a second plurality of UEs within a coverage area <NUM> of the eNB <NUM>. The second plurality of UEs includes the UE <NUM> and the UE <NUM>. In some embodiments, one or more of the eNBs <NUM>-<NUM> may communicate with each other and with the UEs <NUM>-<NUM> using <NUM>, LTE, LTE-A, WiMAX, WiFi, or other wireless communication techniques.

Depending on the network type, the term "base station" or "BS" can refer to any component (or collection of components) configured to provide wireless access to a network, such as transmit point (TP), transmit-receive point (TRP), an enhanced base station (eNodeB or eNB), a <NUM> base station (gNB), a macrocell, a femtocell, a WiFi access point (AP), or other wirelessly enabled devices. Base stations may provide wireless access in accordance with one or more wireless communication protocols, e.g., <NUM> 3GPP new radio interface/access (NR), long term evolution (LTE), LTE advanced (LTE-A), high speed packet access (HSPA), Wi-Fi <NUM>. 11a/b/g/n/ac, etc. For the sake of convenience, the terms "BS" and "TRP" are used interchangeably in this patent document to refer to network infrastructure components that provide wireless access to remote terminals. Also, depending on the network type, the term "user equipment" or "UE" can refer to any component such as "mobile station," "subscriber station," "remote terminal," "wireless terminal," "receive point," or "user device. " For the sake of convenience, the terms "user equipment" and "UE" are used in this patent document to refer to remote wireless equipment that wirelessly accesses a BS, whether the UE is a mobile device (such as a mobile telephone or smartphone) or is normally considered a stationary device (such as a desktop computer or vending machine).

It should be clearly understood that the coverage areas associated with eNBs, such as the coverage areas <NUM> and <NUM>, may have other shapes, including irregular shapes, depending upon the configuration of the eNBs and variations in the radio environment associated with natural and man-made obstructions.

As described in more detail below, one or more of the UEs <NUM>-<NUM> include circuitry, programing, or a combination thereof, for efficient beam recovery in an advanced wireless communication system. In certain embodiments, and one or more of the eNBs <NUM>-<NUM> includes circuitry, programing, or a combination thereof, for receiving efficient beam recovery in an advanced wireless communication system.

For example, the wireless network could include any number of eNBs and any number of UEs in any suitable arrangement. Also, the eNB <NUM> could communicate directly with any number of UEs and provide those UEs with wireless broadband access to the network <NUM>. Similarly, each eNB <NUM>-<NUM> could communicate directly with the network <NUM> and provide UEs with direct wireless broadband access to the network <NUM>. Further, the eNBs <NUM>, <NUM>, and/or <NUM> could provide access to other or additional external networks, such as external telephone networks or other types of data networks.

<FIG> illustrates an example eNB <NUM> according to embodiments of the present disclosure. The embodiment of the eNB <NUM> illustrated in <FIG> is for illustration only, and the eNBs <NUM> and <NUM> of <FIG> could have the same or similar configuration. However, eNBs come in a wide variety of configurations, and <FIG> does not limit the scope of this disclosure to any particular implementation of an eNB.

As shown in <FIG>, the eNB <NUM> includes multiple antennas 205a-205n, multiple RF transceivers 210a-210n, transmit (TX) processing circuitry <NUM>, and receive (RX) processing circuitry <NUM>. The eNB <NUM> also includes a controller/processor <NUM>, a memory <NUM>, and a backhaul or network interface <NUM>.

The controller/processor <NUM> can include one or more processors or other processing devices that control the overall operation of the eNB <NUM>. For example, the controller/processor <NUM> could control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceivers 210a-210n, the RX processing circuitry <NUM>, and the TX processing circuitry <NUM> in accordance with well-known principles. The controller/processor <NUM> could support additional functions as well, such as more advanced wireless communication functions. For instance, the controller/processor <NUM> could support beam forming or directional routing operations in which outgoing signals from multiple antennas 205a-205n are weighted differently to effectively steer the outgoing signals in a desired direction. Any of a wide variety of other functions could be supported in the eNB <NUM> by the controller/processor <NUM>.

The backhaul or network interface <NUM> allows the eNB <NUM> to communicate with other devices or systems over a backhaul connection or over a network. For example, when the eNB <NUM> is implemented as part of a cellular communication system (such as one supporting <NUM>, LTE, or LTE-A), the interface <NUM> could allow the eNB <NUM> to communicate with other eNBs over a wired or wireless backhaul connection. When the eNB <NUM> is implemented as an access point, the interface <NUM> could allow the eNB <NUM> to communicate over a wired or wireless local area network or over a wired or wireless connection to a larger network (such as the Internet).

Although <FIG> illustrates one example of eNB <NUM>, various changes may be made to <FIG>. For example, the eNB <NUM> could include any number of each component shown in <FIG>. As another particular example, while shown as including a single instance of TX processing circuitry <NUM> and a single instance of RX processing circuitry <NUM>, the eNB <NUM> could include multiple instances of each (such as one per RF transceiver).

The RF transceiver <NUM> receives, from the antenna <NUM>, an incoming RF signal transmitted by an eNB of the network <NUM>.

The processor <NUM> is also capable of executing other processes and programs resident in the memory <NUM>, such as processes for CSI reporting on PUCCH. The processor <NUM> can move data into or out of the memory <NUM> as required by an executing process. In some embodiments, the processor <NUM> is configured to execute the applications <NUM> based on the OS <NUM> or in response to signals received from eNBs or an operator. The processor <NUM> is also coupled to the I/O interface <NUM>, which provides the UE <NUM> with the ability to connect to other devices, such as laptop computers and handheld computers. The I/O interface <NUM> is the communication path between these accessories and the processor <NUM>.

The network operator, or a <NUM>rd party service provider on behalf of the operator, can setup up uplink services. In this disclosure, following embodiments are provide: uplink service discovery so that end users can discover available uplink services in the PLMN the end users currently reside; procedure for accessing uplink service using control protocols and APIs; and bootstrapping session setup protocols using APIs so end user clients and uplink services successfully setup sessions for content upload and streaming.

Following are the new features described in the present disclosure: domain naver system (DNS) records that help resolve the location of uplink service to the UE; discovery of an uplink service based on interested service features; signaling mechanism for accessing available uplink services; and selection of framework for live uplink streaming (FLUS) sink based on FLUS source characteristics and capabilities.

Through the embodiments provided by the present disclosure, following advantages are provided: be able to resolve the location of the available uplink services provided by the operator or a <NUM>rd party service provider on behalf of the operator; provision domain names of uplink services using different methods such as pre-configuration, device management, and DNS; discovery of subset of uplink services based on interested features; and signaling mechanisms for end user clients to access the available uplink services.

<FIG> illustrates an example uplink service architecture in operator's network <NUM> according to embodiments of the present disclosure. The embodiment of the uplink service architecture in operator's network <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of this disclosure to any particular implementation.

<FIG> shows a simple architecture of uplink services that are provided by the operator or by an external <NUM>rd party service provider. If the uplink services are provided by the operator, the uplink services reside in the operator PLMN and are accessible to the users. On the other hand, a <NUM>rd party service provider can also provide an uplink service to operator's users by having business agreements with the operator. From herein, it is referred to the provider of uplink services, either the network operator or the <NUM>rd party service provider, as uplink service provider.

Once the uplink service is deployed, the users of the operator (e.g., UE<NUM>) can setup one or more media sessions to upload service content to the uplink service. The media session setup between the end user and the uplink service is done through the control nodes of the operator network, while the actual service content flows from the end user to the uplink service through the data forwarding nodes of the operator network as shown in <FIG>. Any time after the content upload, depending on the service configuration as setup by the end user, the uplink service can distribute the content to interested users in the downlink direction (e.g., UE<NUM>).

For realizing the uplink service, there are many steps that are required to be performed before the uplink service starts delivering the content to interested users in downlink direction. These steps are discussed in detailed below.

In one step of domain names for uplink services, as a first step towards the discovery of available uplink services, the end user clients have to be aware of domain names of all uplink service providers supported by the operator. In one embodiment of this disclosure, it is provided that all the domain names of different uplink service providers may be pre-configured in the device. Alternative domain name configuration options are provided in subsequent embodiments.

When the domain names of all the available uplink service providers are pre-configured in the system, the end user client, when the end user client intends to use an uplink service, can pick one of the domain names in the pre-configured domain name list of uplink service providers for the domain names use. The criteria for selecting one uplink service provider among all the uplink service providers is left to the end user and could be dependent upon the features provided by the uplink service, charges for using the uplink service, operator policy etc. Once the end user chooses an uplink service provider, the end user client can use the domain name of the chosen uplink service provider to discover location of uplink services as described in next section.

In one step of uplink service discovery, once the end user chooses an uplink service provider, the end user client can proceed to discover the uplink service the end user client wants to use. The discovery of uplink service can be done in two different ways: discover all available uplink services and then filter what services the end user wants to use; and discover available uplink services that support specific features required by the end user.

In one step of discovery of all Available uplink services and then filter for interested ones, in this type of discovery, the end user client, through the discovery mechanisms, first discovers the list of all available uplink services. Then the end user client can choose an uplink service that the end user client wants to use and proceed to obtain the capabilities of the uplink service as described in this section. Optionally, if the end user client cannot decide on an uplink service, then the end user client can obtain the capabilities of all available uplink services and then choose one uplink service that the end user client is interested in.

One way of discovering available uplink services is through domain name service (DNS) records. The network operator configures the DNS with uplink service location information so the end user can discover the location and supported features of those uplink services as described below.

For discovery of available uplink services provided by an uplink service provider, the network operator creates DNS SRV records as follows. For service records, the DNS SRV record format is given by: service. domainname. TTL class SRV priority weight port target.

For uplink service, it is provided to create a new DNS SRV record with service name "flus. " So, with the service name "flus" and uplink provider domain name (e.g., "operator. com"), the network operator creates a DNS SRV record for uplink service as shown in the following example: _flus. <NUM> IN SRV <NUM><NUM><NUM> api.

As defined in the above DNS SRV record, the service "flus" can be reached at the location api. com at port <NUM> and protocol TCP with a priority value of <NUM> and weight value of <NUM>. Similar to above record, the operator can define additional locations (target and port) with a different priority and weight value. Depending on the priority and weight value, when a request to access service "flus" comes to the operator DNS, the DNS server may resolve the request to a particular target. Once the location is resolved, the end user client is now aware of the location of the uplink service at the uplink service provider.

Optionally, the uplink service can also provide a SIP end point and provide these details using another DNS SRV record. So, with the service name "flus" and uplink provider domain name (e.g., "operator. com"), the network operator creates a DNS SRV record for uplink service as shown in the following example: for SIP over TCP: _flus. <NUM> IN SRV <NUM><NUM><NUM> sip. ; and for SIP over UDP: _flus. <NUM> IN SRV <NUM><NUM><NUM> sip.

The end user client can retrieve the DNS SRV record as defined above to know the location of the uplink service. However, more information about the service cannot be delivered using the DNS SRV record. For this reason, DNS TXT record is used to inform end user clients of optional information about the uplink service. For TXT records, the DNS TXT record format is:_service. domainname. TTL class TXT "param_1=value_1;param_2=value_<NUM>. param_n=value_n" where param_1. param_n are the "n" number of parameters whose values are value _1. value_n, respectively.

For uplink service, it is provided to create a new DNS TXT record with service name "flus. " So, with the service name "flus" and uplink provider domain name (e.g., "operator. com"), the network operator creates a DNS TXT record for uplink service as shown in the following example:_flus. <NUM> IN TXT "supported_control_protocols={sip, http, MMT}; http_uri=/uplinkservices.

From the above TXT record, it can be observed that the uplink service "flus" supports control protocols SIP, HTTP, and MMT, and the URI for accessing through HTTP is /uplinkservices.

Using both the DNS SRV and TXT records, the end user client can construct a complete HTTP URI api. com/uplinkservices and access this URI at target location api. com and port <NUM>.

In DNS TXT records, various parameters can be included that gives more information about the service. TABLE <NUM> shows the different parameters that can be included in the TXT records to give more information about uplink service to the end user clients. TABLE <NUM> exemplifies a list of parameters in DNS TXT record for uplink service.

Once the end user client decides on an uplink service that the end user client wants to use and is aware of all the capabilities of the said uplink service, the end user client can proceed to perform session setup with that uplink service.

In one embodiment of discovery of all available uplink services that support specific features, with this type of discovery, instead of discovering all available uplink services at the uplink service provider, the end user client can discover uplink services that support specific features that the end user is interested in. As a result of this discovery mechanism, the end user client only has a subset of uplink services from which the end user client has to choose an uplink service. The advantage of this discovery mechanism over the previous mechanism is that, using this mechanism, the operator has more control on uplink service selection by the end user client.

This mechanism of discovering uplink services that support specific features can be done by extending DNS. It is provided to enhance the DNS request from the end user client to DNS server to include a field called "interested_features" whose value provides the list of features the end user is interested in. When the DNS server gets this request, the DNS returns back with DNS records (SRV and TXT records in format described before) of only those uplink services that support the features requested by the end user client.

Once the end user client gets the subset of uplink services, the end user client can decide on the uplink service the end user client is interested in and then proceed to setup session with that uplink service as described in the next section.

In one embodiment of discovery of FLUS sink based on source characteristics and/or capabilities, uplink services or a FLUS sink can be selected based on source characteristics and/or capabilities (e.g., camera parameters when the source has a camera arrangement at the capturing side). When a request from the end user with capability or characteristics information of the capturing system comes to the FLUS service operator, a FLUS sink can be dynamically selected and provisioned based on the information in the incoming request. The FLUS operator can choose an appropriate FLUS sink based on this information instead of pre-configuring a generalized FLUS sink to service a request from a source with any kind of capabilities and/or characteristics.

Alternatively, the FLUS operator can publish a directory of FLUS sinks that support a given set of source characteristics and/or capabilities. Such information can be published using the DNS SRV and TXT records described earlier. When FLUS source devices require to use a FLUS sink, the FLUS source devices can use such DNS information to infer appropriate FLUS sinks as FLUS source devices are aware of their own characteristics/capabilities and the characteristics/capabilities of all FLUS sinks provided by the FLUS operator.

In one embodiment of service configuration and session setup with uplink services, once the end user client chooses an uplink service the end user client wants to use, the end user client can proceed with service configuration and signaling session setup using any of the control protocols supported by the uplink service (as indicated using supported_control_protocols parameter in Table-<NUM>). In such embodiment, a mechanism is provided for session setup using REST APIs that uses HTTP protocol. In one embodiment, an alternate method of session setup using an offloaded control protocol is provided.

Using REST APIs, the end user client can configure a service and setup a session with the uplink service as shown in the below example:
<IMG>.

As shown above, the end user UE can request a session setup using REST API with the uplink service. TABLE <NUM> shows a brief description of each of the content body fields inside the POST request. TABLE <NUM> exemplifies a list of parameters in Session setup requests to uplink service.

Based on the POST request from the end user client with fields described above, the uplink service can return back to the end user client with a <NUM> OK success message as described below:
<IMG>.

Using the <NUM> OK response message, the uplink service can acknowledge the receipt of session creation request. Optionally, if the uplink service requests end user authentication, the uplink service can respond back with a <NUM> message. If the request cannot be fulfilled, the uplink service can respond back with a <NUM> Forbidden message.

<FIG> illustrates an example session setup procedure <NUM> with uplink services according to embodiments of the present disclosure. The embodiment of the session setup procedure <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of this disclosure to any particular implementation.

Once the end user client receives a success message from the uplink service, the end user client can start uploading content to uplink service. After all the content is received from the end user client, the uplink service can perform downlink content distribution as described later in the disclosure. The above session setup procedure is as shown in <FIG>.

In one embodiment of session setup using offloaded control protocol, as discussed in previously, the end user client can configure services and setup sessions with an uplink service. However, it is also possible that the end user client and uplink service can offload certain aspects of the signaling setup to another control protocol.

In the aforementioned embodiment, an example session setup with offloading to SIP protocol is provided. To offload session setup to SIP, the end user and uplink service do the following.

In one example, the end user client can retrieve the DNS SRV and TXT records as described in the aforementioned embodiments to retrieve service location and other service information. From the supported_control_protocols parameter in DNS TXT record, the end user client can infer that the uplink service supports other control protocols (e.g., SIP).

In one example, using the REST API invocation as described in aforementioned embodiments, the end user client can configure the service and start session setup with the uplink service. In the POST request to the uplink service, the end user client can include a field called "offload-control-protocol" and set the field's value to "sip.

In one example, when the uplink service receives this POST request, the uplink service acknowledges the switch over to offload control protocol using the field "offload-control-protocol" with value "sip" inside the <NUM> OK message to the end user client.

In one example, when the end user client receives a <NUM> OK message with field "offload-control-protocol" with value "sip," the end user client infers that the uplink service is ready to switch to control protocol SIP. The end user client may then switch to using SIP.

In one example, the end user client may then find the location of uplink SIP service as described in the aforementioned embodiments. Optionally, the uplink service can give the SIP endpoint location in the <NUM> OK message to end user client in step-<NUM> above. The end user client may send SIP requests to continue the session setup process.

<FIG> illustrates an example session setup procedure <NUM> using offloaded control protocol according to embodiments of the present disclosure. The embodiment of the session setup procedure <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of this disclosure to any particular implementation.

The end user client and uplink service can proceed with normal SIP signaling to continue and complete the session setup process. Once the session is setup, the end user client can stream content to the uplink service which the uplink service can later distribute in downlink direction as described later in the disclosure. The above session setup procedure that starts with an API and ends with an offloaded control protocol can be shown in <FIG>.

In one embodiment of correlation during offloading to control protocol, using the offloading to control protocol procedure described above, the end user client switches from one signaling mechanism (e.g., REST API) to another (e.g., SIP). During this switch, it is required that the end points hold the state so the end points know which signaling of the former (e.g., REST API) corresponds to which signaling of the later (e.g., SIP).

To support the correlation between these two signaling mechanisms, it is provided that a unique identifier is provided from one signaling mechanism to another signaling mechanism. When the end points negotiate with the first signaling mechanism, the end user client includes this unique identifier which the uplink service end point caches and saves the unique identifier. Later when the end user client and uplink service endpoint decide to switch to another control protocol, the end user client may include the unique identifier in second signaling mechanism to the uplink service end point so the uplink service knows which session in first signaling mechanism corresponds to which session using second signaling mechanism.

With the above correlation, the session setup using the two signaling mechanisms REST API and SIP is as described below.

In one example, end user client sets up a session with REST API as described before, but with a minor change. In the session setup request using REST API, the end user sends a field called "session_identifier" whose value is a unique numeric string (e.g., "Offload_Identifier_Value"). When the uplink service endpoint receives the session setup request with this identifier, the uplink service endpoint saves the identifier for later signaling mechanism offload.

In one example, the end user client and uplink service endpoint switch to control protocol SIP as described before, but with one minor change. The end user client enhances the SIP signaling request using any of the following mechanisms. In one instance, introduce a field called "X-Offload-Identifier" in SIP message with the same value "Offload_Identifier_Value" as generated above. In another instance, enhance the Origin field of SDP. One of the parameters in origin field of SDP is "session-id". For the session-id value of Origin field, it is provided to include the value of "Offload_Identifier_Value" generated above. In yet another instance, enhance SDP with a value attribute called "Offload_Identifier" whose value is same as "Offload_Identifier_Value" generated above. For example, the value attribute in SDP may appear as "a=Offload _Identifier:<Offload_Identifier _Value>.

Based on the unique identifier in either SIP or SDP described above, the uplink service endpoint may clearly know which REST API session does this SIP signaling corresponds to: the end user client and uplink service end point can complete the session setup using SIP as described before.

In one embodiment of downlink distribution of content, once the end user client sets up session with uplink service using any of the methods described before, the end user client starts streaming content to the uplink service. The uplink service can then optionally transform the content (e.g., transcoding, application of features) as requested by the end user client and host the content. Depending on the service configuration, the uplink service may distribute the content to downlink users using techniques such as MBMS and PSS.

Device management techniques such as OMA can be used for configuring/providing information of uplink services to the end user clients. Different levels of information can be provided such as: domain names of uplink services which the end user clients can use along with DNS records to retrieve the list of uplink services provided by the service provider and then further lookup the location of each of the interested uplink service; list of available uplink services with detail information (as described in TABLE <NUM>) about each of the uplink service. When the end user client receives detail information of each of the available uplink service, the client can decide on the uplink service the client is interested in and can directly proceed to setup a session with the chosen uplink service as described in the embodiment; and location of uplink service directory service which the end user client can query to discover available uplink services and details about interested uplink services.

In one embodiment of uplink service discovery using "uplink service directory," as specified in the aforementioned embodiments, sometimes it could be an overkill to have DNS SRV and TXT records of each and every uplink service offered in the operator network. A solution to this problem is a service called uplink service directory (USD). An USD is a service that holds a repository of all uplink services in the operator domain. Instead of configuring the SRV records of each of every uplink service offered in the PLMN, the operator can just configure the SRV record of the USD in the operator domain as follows:_flus. <NUM> IN SRV <NUM><NUM><NUM> usd.

The end user clients, as described in other embodiments, are either pre-configured or informed through device management techniques with the domain name where the USD service is hosted. Once the end user clients have the domain name, the end user clients use the above DNS SRV record to retrieve the location of the USD service in the operator network. The USD service can host an HTTP server and offer end points (e.g., REST end point) for end user clients to query. To signal the capability of HTTP service to end users, the operator can configure a DNS TXT record such as the following: _flus. <NUM> IN TXT " http_uri=/getuplinkservices.

Using the DNS SRV and TXT records the end user clients can compose the HTTP URI of the USD service. The end user client can then send a GET request using REST API to the USD service to retrieve the set of all uplink services offered in the operator network as shown below:.

When the USD service gets a GET request from the end user client, the USD service can respond back with a <NUM> OK message which includes the list of all uplink services offered in the operator network as shown below:
<IMG>.

After retrieving the list of all available uplink services, the end user client can choose an uplink service that the user is interested in, and then proceed to setup sessions with an uplink service as described in the embodiments. Alternatively, the <NUM> OK response can contain only the location information of each of the available uplink service. In this case, the end client can send a GET service to with URI /getuplinkservices/service Id to receive the detail information of the uplink service with Id serviceId which the end client is interested in.

With demands from enhanced multimedia applications are ever increasing (e.g., to provide services such as AR, 6DoF etc.), it becomes more significant that content processing components become more application aware that can provide required level of processing capabilities to the end user. As a result, generalized media processing components cannot serve the diverse type of requests from the source. In case of FLUS, it is expected that the capturing modalities may differ quite significantly. So, the FLUS operator may be required to provide processing infrastructure that can cater to the exact requirements by the end user capturing devices.

In this embodiment, capturing characteristic/capability information is provided using camera parameters that can be sent to FLUS operator so appropriate FLUS sinks can be selected for serving the requests generated from that end user device.

For a capturing system at the FLUS source with one camera, when the capturing system at the FLUS source has only one camera in the arrangement, it is provided that all the characteristics of the camera be sent in the request to the FLUS operator so an appropriate FLUS sink can be selected based on the included characteristics. For example, one or more of the following camera parameters can be sent as characteristics information to the FLUS operator for the single camera so an appropriate FLUS sink can be selected as shown in TABLE <NUM>. Table <NUM> exemplifies characteristic information for camera.

If the camera has audio recording capabilities, one or more of the following camera parameters can be sent as audio characteristics information to the FLUS operator so an appropriate FLUS sink can be selected as shown in TABLE <NUM>. TABLE <NUM> exemplifies audio characteristics information.

For a capturing system at the FLUS source with multiple cameras in a camera arrangement, if the capturing system at the FLUS source has multiple cameras in the camera arrangement, one or more of the following set of parameters can be sent to the FLUS operator so an appropriate FLUS sink can be selected as shown in TABLE <NUM>. TABLE <NUM> exemplifies parameters for FLUS operator.

In addition to the camera arrangement information such as above, individual parameters of each camera as described earlier can also be sent to the FLUS operator so an appropriate FLUS sink can be selected.

If multiple cameras in the camera arrangement also have audio recording capabilities, following set of parameters can be sent to the FLUS operator so an appropriate FLUS sink can be selected as shown in TABLE <NUM>. TABLE <NUM> exemplifies parameters for the FLUS sink.

In addition to the audio information about the arrangement such as above, individual audio parameters of each camera as described earlier can also be sent to the FLUS operator so an appropriate FLUS sink can be selected.

In one embodiment for a well-known capturing system with only one camera at the FLUS source, if the capturing system at the FLUS is a well-known capturing system with one camera, it is provided that a well-known camera identifier may be sent to the FLUS operator so the operator can select an appropriate FLUS sink for the request. Optionally, the FLUS source can also send individual camera video and audio characteristics for the camera as defined earlier to the FLUS operator.

In one embodiment for a well-known capturing system at the FLUS source, if the capturing system at the FLUS is a well-known capturing system with multiple cameras (e.g., GoPro Omni, Facebook Surround <NUM>, Samsung Gear <NUM> etc.), it is provided that a well-known camera system identifier be sent to the FLUS operator so the operator can select an appropriate FLUS sink for the request. Optionally, the FLUS source can also send camera arrangement information and individual camera video and audio characteristics for each camera in the camera arrangement as defined earlier to the FLUS operator.

As described in the aforementioned embodiment, DNS SRV and TXT records can give uplink service or FLUS sink information that the end user clients can use to select appropriate FLUS sink. In addition to the parameters described in the embodiments, the DNS TXT records can also give information about the camera parameters described in alternative embodiment <NUM> above. When such parameters are incorporated into the DNS system, when the end user clients read the DNS SRV and TXT records as described in aforementioned embodiments, the end user clients can now select FLUS sinks not only based on the type of services, but also based on the type of characteristics or capabilities (e.g., camera parameters) of the end user clients. As a result, such FLUS sinks can only be restricted to be used with FLUS source devices that possess such kind of capabilities.

In the present disclosure, method for discovery of uplink services based on uplink service capabilities and end user requirements is provided. In the present disclosure, uplink services and their capabilities that are published inside the operator network is provided.

Following are the advantages of the present disclosure: different endpoints of a service can now be configured with different capabilities and the network packet processing entities can now discover appropriate endpoints based on these capabilities; and facilities for service providers to provide different service endpoints with different capabilities and mechanisms for publishing their capabilities so appropriate endpoints can be selected during the endpoint selection processes.

<FIG> illustrates another example uplink service architecture <NUM> in operator's network according to embodiments of the present disclosure. The embodiment of the uplink service architecture <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of this disclosure to any particular implementation.

<FIG> shows a simple architecture of operator network providing uplink services. The operator network provides a number of uplink services that can be accessed by the end users. The end user can connect to any of the uplink services and can avail the services provided by the service. Once the end user connects to an uplink service, the end user client can stream content to the uplink service. Depending on the end user interests and configuration, the uplink service can either store content for later distribution or start distributing the content to interested users.

For complete realization of the FLUS (Flexible Live Uplink Service) service, the end user client, on behalf of the end user indicates to the operator network that the end user client intends to use the services of an uplink service that provides certain features and capabilities. When the message processing entity of the operator network receives such a request the message processing entity of the operator network needs to select an uplink service endpoint that provides such a service with the requested capabilities. There is existing literature that specifies how different messages from the end user client can be diverted to different services.

In addition, there is lot of literature that describes how the destination endpoint is to be selected based on the destination information in the incoming messages from the end user client. However, such a mechanism implies that the end user client is already aware of the destination endpoint information and the network is just providing control and user plane paths to the requested destination. Such kind of mechanisms does not work when the end user client is not aware of the endpoint information of a server that is providing an uplink service of end user's choice. In this case, the end user client usually uses a generic service request (e.g., FLUS request) and relies on the capabilities of the operator network to divert the request to the appropriate destination endpoint.

In the present disclosure, a method is provided for selecting the appropriate end point for diverting the generic request from the end user client. As shown in <FIG>, when the request from the end user client with a generic request reaches the operator network, the signaling function inside the operator network uses the selection function to select the appropriate uplink service endpoint. The selection of an appropriate uplink service endpoint is based on the capabilities of the uplink service endpoint as known to the Selection Function.

The selection function, based on the messages from the end user client, may select an uplink service endpoint and returns the information to the signaling function. When the signaling function receives the information about the appropriate uplink service endpoint from the selection function, the signaling function may divert the message from the end user client to the selected uplink service endpoint. When the uplink service endpoint receives the message forwarded by the signaling function, the uplink service endpoint can respond back to the end user client. The uplink service endpoint and the end user client may then continue with the session setup and the end user client can stream content as intended by the end user.

<FIG> illustrates an example publishing uplink service capabilities <NUM> according to embodiments of the present disclosure. The embodiment of the publishing uplink service capabilities <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of this disclosure to any particular implementation.

As described above, the selection function may select the appropriate uplink service endpoint based on the capabilities of each of the uplink service endpoints in the operator domain. For this to be possible, the operator can setup a directory service to which all the uplink service endpoints may publish their capabilities. This is shown in <FIG>.

As shown in <FIG>, the operator can provide a directory & publish function for use of uplink services. Each uplink service endpoint may register each uplink service endpoint's capabilities with the directory & publish function. So, when the UE makes FLUS uplink service request, the signaling function can request the Selection Function for the endpoint information of the uplink service that can service the end users request. The selection function can then use the directory & publish function to infer the capabilities of each of the uplink service endpoints. Based on the inferred capabilities, the Selection Function can then inform the signaling function which may then forward the request to the selected uplink service endpoint as described before.

As described above, the capabilities of each of the uplink services can be published to the directory & publish Function. The kind of capabilities that can be published for uplink service endpoints are as shown in TABLE <NUM>. TABLE <NUM> exemplifies a list of capabilities of uplink service.

As shown in TABLE <NUM>, different capabilities of each of the uplink service endpoint along with the endpoint contact information can be stored in the directory & publish function. This information may form the basis for selection of appropriate uplink service endpoint when the FLUS session request comes from the end user client.

The FLUS uplink services can be provided for IMS users. So, operators providing IMS services to operators' end users can provision FLUS services and have their end users use IMS signaling and IMS service infrastructure for delivery of FLUS services.

<FIG> illustrates an example uplink service <NUM> in operator's IMS domain according to embodiments of the present disclosure. The embodiment of the uplink service <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of this disclosure to any particular implementation.

As shown in <FIG>, with IMS, the end users use IMS signaling (using SIP and SDP protocols) to connect to the IMS network. The IMS clients can then request the Signaling Functions (e.g., CSCF's in IMS) for FLUS service. Upon receiving the FLUS service request as part of the SIP signaling request from the end user client, the CSCF server can use the selection function and directory & publish functions to select the appropriate uplink service endpoint. When the appropriate uplink service endpoint gets identified, the SIP signaling from the end user client (IMS client) is forwarded to the selected endpoint. Once the end point receives the SIP signaling request from the end user client for FLUS service, the endpoint can respond back to the end user client and both of them can continue the session setup process.

As described in the present disclosure, the capabilities of each of the uplink service endpoints are published in the directory & publish function. In IMS, such a function can be implemented as described in the aforementioned embodiments. For facilitating the directory service, each uplink service endpoint may act as an SIP application server (AS). Each uplink service AS may then publish each uplink service AS's capabilities to such directory service in the operator's IMS network.

For publishing of uplink service capabilities into the directory service, one of the following options can be followed. In one example of option <NUM> (SIP REGISTER), each of the uplink service AS can send each of the uplink service AS's capabilities to the directory service using SIP REGISTER method.

As messages with SIP REGISTER method allow registration of SIP entities, the uplink services can register their location and the uplink services' capabilities as shown below: an uplink service (example with URI sip:upserv1@flus. com) can register the uplink service's capabilities by sending the following SIP REGISTER method to the directory and service function (example with URI sip:dp. The capabilities described in this example are not comprehensive and can include lot of addition details about the flus uplink service. <IMG>
<IMG>.

For the above REGISTER request from the uplink service, the directory & publish function SIP endpoint can send back an acknowledgement as shown below:
<IMG>.

As described in the SIP REGISTER exchange above, each flus uplink service can register each flus uplink service's capabilities to the directory & publish function in the IMS network.

In one example of Option <NUM> (SIP OPTIONS), the directory service can function in a UAC role and request the capabilities of each uplink service endpoint using the SIP OPTIONS method. When each of the uplink service endpoints receive such a SIP OPTIONS method request from the directory service UA, each of the uplink service endpoints can respond back to the directory service UA with details of each of the uplink service endpoints' capabilities.

For knowing the capabilities of an uplink service, the directory & publish function may know the SIP URI of the uplink service so the directory & publish function can send an OPTIONS query to that uplink service. The location of the uplink service can be known to the directory & publish function in two ways: the IMS network administrator statically configures the SIP URI of each of the uplink services in the directory & publish function so the IMS network administrator knows where to send the SIP OPTIONS query to; and optionally, each uplink service can register each uplink service's location with the directory & publish function using the SIP REGISTER request above, but without the service capabilities information. Once the directory & publish function knows the location, the directory & publish function can send an OPTIONS query to the uplink service.

Once the directory & publish function knows the SIP URI (or location) using any of the methods described above, the directory & publish function can send an OPTIONS query to each of the uplink service. For example, below is an SIP OPTIONS message to an uplink service requesting capabilities:
<IMG>.

When the uplink service gets an OPTIONS request from the directory & publish function, the uplink service can respond back with the uplink service's capabilities in the <NUM> OK message as shown below:
<IMG>
<IMG>.

The directory & publish function can send such OPTIONS query to each uplink service in the IMS domain and the directory & publish function can receive the capabilities of all the uplink services in the IMS domain.

In one example of option <NUM> (using SIP MESSAGE), each of the uplink service AS can send each of the uplink service AS's capabilities to the directory service using SIP MESSAGE method. As messages with SIP MESSAGE method allows sending of textual data, the uplink server endpoint can send each of the uplink service AS's capabilities to the directory service.

For the uplink service to send the uplink service's capabilities using SIP MESSAGE, the uplink service may have a SIP session with a SIP UA provisioned in the IMS network. Once the uplink service sets up a session, the uplink service can send the following SIP MESSAGE request to inform the IMS network of the uplink service's capabilities:
<IMG>
<IMG>.

When the SIP UA in the IMS network receives the above SIP MESSAGE request, the SIP UA can store the capabilities of the uplink service so the uplink service can be discovered when necessary.

In one example of Option <NUM> (using SIP INFO), each of the uplink service AS can send each of the uplink service AS capabilities to the directory service using SIP INFO method.

For the uplink service to send the uplink service's capabilities using SIP INFO request, the uplink service may have a SIP session with a SIP UA provisioned in the IMS network. During the SIP session setup, for an INVITE request from the uplink service, the SIP UA, in the SIP UA's <NUM> OK response to the uplink service, may indicate support that the SIP UA may receive INFO requests for package "flus" as described in the aforementioned embodiments. Once the uplink service sets up a session, the uplink service can send the following SIP INFO request to inform the IMS network of the uplink service's capabilities:
<IMG>
<IMG>.

When the SIP UA in the IMS network receives the above SIP INFO request, the SIP UA can store the capabilities of the uplink service so the uplink service can be discovered when necessary.

Using any of the options defined above, the directory service gets to know the capabilities of each of the uplink service endpoints in the operator's IMS network.

As described in the aforementioned embodiments, with IMS, the FLUS end user client (IMS client) may send a request to the IMS network which the IMS network message processing entities (CSCF servers) forward to the appropriate uplink service endpoint. The selection of the appropriate uplink service endpoint is based on the capabilities of uplink service AS servers implementing FLUS services as described in the aforementioned embodiments.

For the IMS network to perform selection of appropriate uplink service endpoints, it may need: information from the IMS FLUS clients about the capabilities requiring for the FLUS service; and metadata describing the end user client's media and capture information and the end user client's capabilities.

The UE capability information described above cannot be exchanged using the mechanisms described in the known-reference as the mechanisms that are used to provide client's preferences to the server which are usually static. However, for FLUS service, the UE capabilities might vary for every session with a FLUS service. In addition, the caller preferences described in the known-reference do not provide any tags for exchange of capabilities required for FLUS service.

The IMS clients can perform one of the following to inform the IMS network about the IMS clients' own capabilities, media and capture information, and capabilities required for the FLUS service.

In one example of Option <NUM> (using new SIP custom header), IMS client can use a new SIP header called "P-FLUS-Service" in the IMS client's SIP INVITE message to the IMS network. As value of this header, the IMS client can include all the details described in the aforementioned embodiments.

An example SIP INVITE request with the above custom header can be shown as follows:
<IMG>.

As shown in the above SIP INVITE request, a UE is requesting session setup with an uplink service which can provide a <NUM> stitching service for video with two camera feeds in h265 format. These capabilities are included in the P-FLUS-Service custom header. The SDP in the INVITE contains information where the SDP can receive the final stitched video.

When the IMS network receives the above SIP INVITE request, the IMS network can extract the UE requested feature (<NUM> stitching in above message example) and feature metadata (video format, number of cameras), find an uplink service that provides the above feature supporting the requested metadata. Once the IMS network finds an uplink service that supports this feature and metadata using the directory & publish function (e.g., upserv1 described earlier), the IMS network forwards the INVITE request to that uplink service (upserv1).

The uplink service (upserv1) may then complete the session setup. The SDP in the response from the uplink service may indicate two media descriptions describing where the SDP can receive the two camera feeds originating from the UE. Once the UE and the uplink service perform the session setup, the UE can stream the two camera feeds as RTP stream. The uplink service may then perform the requested service (<NUM> video stitching) and may respond back with the stitched video to the UE.

In one example of option <NUM> (using SIP MESSAGE), IMS client can perform a regular IMS session setup with a user agent setup by the operator in the IMS network. Upon successfully establishing the IMS session, the IMS client uses SIP MESSAGE method to indicate all the details described in the aforementioned embodiments. When the SIP UA in the IMS network receives this message, the SIP UA can extract the details of the IMS client and then perform the appropriate uplink service selection mechanism described in the aforementioned embodiments.

For the IMS client to use SIP MESSAGE request to inform the IMS network about the service the IMS client requires, the IMS client (UE) can first setup a SIP session as described in the aforementioned option <NUM> without the SIP custom header P-FLUS-Service. The session is setup with a SIP UA provisioned by the IMS operator. Once the UE has a SIP session with the SIP UA in the IMS network, the UE can send the following SIP MESSAGE request to inform the IMS network about the services the UE requires:
<IMG>
<IMG>.

As shown in the above SIP MESSAGE request, the UE informs the IMS network of the uplink service the UE requires. In the xml body above, the UE indicates that the UE needs a <NUM> video stitching service with two camera feeds in h265 format. When the SIP UA in the IMS network receives this SIP MESSAGE request, the SIP UA uses the Directory & Publish function to find an uplink service that can provide the requested feature. Once the SIP UA finds the appropriate uplink service (e.g., upserv1 described earlier), the SIP UA can request the IMS client (UE) to do a SIP re-INVITE with the identified uplink service. Once the uplink service (upser1) receives the INVITE from the IMS client, the uplink service can proceed to complete the session setup with the IMS client and deliver the service as requested by the UE.

In one example of option <NUM> (using SIP INFO), IMS client can perform a regular IMS session setup with a user agent setup by the operator in the IMS network. Upon successfully establishing the IMS session, the IMS client uses SIP INFO method to indicate all the details described earlier in the aforementioned embodiments. When the SIP UA in the IMS network receives this SIP INFO message, the SIP UA can extract the details of the IMS client and then perform the appropriate uplink service selection mechanism described earlier.

For the IMS client (UE) to use SIP INFO request to inform the IMS network about the service the IMS client (UE) requires, the IMS client (UE) can first setup a SIP session as described in Option <NUM> without the SIP custom header P-FLUS-Service. The session is setup with a SIP UA provisioned by the IMS operator. When the SIP UA in the IMS network responds back to the UE with a <NUM> OK response, the SIP UA can indicate to the UE that the SIP UA may receive INFO requests for package "flus.

Once the UE has a SIP session with the SIP UA in the IMS network, the UE can send the following SIP INFO request to inform the IMS network about the services the UE requires:
<IMG>
<IMG>.

As shown in the above SIP INFO request, the UE informs the IMS network of the uplink service the UE requires. In the INFO message body above, the UE indicates that the UE needs a <NUM> video stitching service with two camera feeds in h265 format. When the SIP UA in the IMS network receives this SIP INFO request, the SIP UA uses the directory & publish function to find an uplink service that can provide the requested feature. Once the SIP UA finds the appropriate uplink service (e.g., upserv1 described earlier), the SIP UA can request the IMS client (UE) to do a SIP re-INVITE with the identified uplink service. Once the uplink service (upser1) receives the INVITE from the IMS client, the uplink service can proceed to complete the session setup with the IMS client and deliver the service as requested by the UE.

In one embodiment, mechanisms are provided for discovery of uplink services using the message processing entities of the IMS network. It is possible that the discovery of FLUS sinks (uplink service endpoints) can be performed using FLUS Management Object which gets provisioned in the UE's device.

The FLUS Management Object may have a management object identifier: "urn:oma:mo:ext-3gpp-flus:<NUM>". The MO may be compatible with OMA Device Management protocol specification version <NUM> and above as described in [OMA-ERELD_DM-VI].

In one embodiment, the following nodes for FLUS configuration are provided.

In one example of Node: /<X>, this interior node specifies the unique object id of a FLUS management object. The purpose of this interior node is to group together the parameters of a single object: occurrence (ZeroOrOne); format (node); and minimum access types (Get).

The following interior nodes may be contained if the FLUS sink in the terminal supports the FLUS Management Object.

In one example of /<X>/Sink/<X>, this node is a collection of information about a FLUS Sink: occurrence (OneOrMore); format (node); and minimum access types (Get).

In one example of /<X>/Sink/<X>/SIPURI, this leaf node provides the SIP URI for the FLUS sink that is described by the parent node: occurrence (One); format (string); and minimum access types (Get).

In one example of/<X>/Sink/<X>/Capabilities, this leaf node provides a URL to the XML document that describes the capabilities of the FLUS sink. The document may follow the syntax and semantics described by the data model: occurrence (ZeroOrOne); format (string); and minimum access types (Get).

In one embodiment, mechanisms are provided for discovery of uplink services using the message processing entities of the IMS network. It is possible that the discovery of FLUS sinks (uplink service endpoints) can be performed using DNS discovery.

If discovery is performed using DNS, a DNS SRV RR request may be sent to the DNS server using the pre-provisioned FQDN: flus. 3gppnetwork.

The response may contain a list of one or more FLUS sinks that are recommended by the network. A TXT RR record may be included to provide a corresponding capability URL for each of the included FLUS sinks in the SRV RR response.

In one embodiment, mechanisms are provided for discovery of uplink services using the message processing entities of the IMS network. It is possible that the discovery of FLUS sinks (uplink service endpoints) can be performed by the network.

The UE may be provisioned with a FLUS URI, e.g. sink@flus. 3gppnetwork. org, in which case, the selection of the FLUS Sink is performed transparently by the S-CSCF.

To assist the S-CSCF with the correct routing of the SIP INVITE request, additional information may be provided as part of the request URI.

The following tag is defined for this purpose: "flus-requirements" and the value may be a URL that points to a document that describes the data model.

An IMS-based FLUS session is established in the same way as a regular MTSI session using a SIP INVITE message. The SDP may include at least one send only media session. Furthermore, to identify that media session as a FLUS session, each FLUS media line may contain an attribute "a=3gpp-flus" with the following ABNF syntax:.

An example of the initial SIP INVITE with the SDP offer is provided here:
<IMG>
<IMG>.

<FIG> illustrates an example flow chart of a method <NUM> for discovery and access uplink services according to embodiments of the present disclosure, as may be performed by an uplink device. The embodiment of the method <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of this disclosure to any particular implementation.

As shown in <FIG>, the method <NUM> begins at step <NUM>. At step <NUM>, the device (e.g., <NUM> - <NUM> as illustrated in <FIG>) identifies parameters for processing the uplink streams of an uplink service. At step <NUM>, the receiving device of the uplink streams is dynamically selected based on at least one of characteristics, capabilities, or requirements associated with the device. At step <NUM>, the set of parameters to capture the uplink stream comprises at least one of a required bandwidth or requested processing steps.

At step <NUM>, the device transmits, to a network entity, a discovery request message including the parameters for discovery of the receiving device capable of processing the uplink stream. At step <NUM>, the discovery request message includes a set of parameters for a camera system.

At step <NUM>, the device receives, from the network entity, a discovery response message including information of the receiving device of the uplink streams.

In one embodiment, at step <NUM>, the device receives, from the network entity, information including a list of available uplink services. In such embodiment, the device determines whether the information is available for establishing the session connection based on a DNS SRV record or a DNS TXT record received from the network entity.

In one embodiment, the device determines a common identifier value that is used for a service configuration with the uplink service and signaling messages used for a session setup with the uplink service.

At step <NUM>, the device establishes a session connection for transmitting the uplink streams to the receiving device for processing the uplink stream based on the discovery request and response messages. In one embodiment, at step <NUM>, a domain name system service (DNS SRV) record and a DNS text (DNS TXT) record include a location of the uplink service, and wherein the uplink service is a framework for live uplink streaming (FLUS) service.

Although the present disclosure has been described with an exemplary embodiment, various changes and modifications may be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims.

Claim 1:
A device (<NUM>) in a wireless communication system, the device comprising:
a transceiver (<NUM>); and
at least one processor (<NUM>) coupled with the transceiver (<NUM>), wherein at least one processor (<NUM>) is configured to:
receive, from an operator, information of a location of a discovery server for discovery of uplink services, wherein the uplink services include a framework for live uplink streaming, FLUS, service,
transmit, to the discovery server, a request message for the discovery of the uplink services, based on the information of the location of the discovery server,
receive, from the discovery server, a response message including information on a list of the uplink services and information on capabilities related to the uplink services;
select an uplink service of the uplink services based on the response message; and
establish a session connection for the uplink service.