Method and system for using relay user equipment in internet protocol multimedia subsystem
阅读说明：本技术 用于在互联网协议多媒体子系统中使用中继用户设备的方法和系统 (Method and system for using relay user equipment in internet protocol multimedia subsystem ) 是由 N·J·鲁塞尔 A·巴克利 S·J·巴雷特 于 2018-07-23 设计创作，主要内容包括：一种用于通过中继用户设备进行互联网协议(IP)多媒体子系统(IMS)通信注册的方法,该方法包括：在中继用户设备处从远程用户设备接收关联消息,关联消息包含远程用户设备标识符；以及响应于该接收,执行从中继用户设备与网络节点的注册,该注册包括远程用户设备与中继用户设备之间的关联。(A method for Internet Protocol (IP) multimedia subsystem (IMS) communication registration by a relay user equipment, the method comprising: receiving, at the relay user equipment, an association message from the remote user equipment, the association message containing a remote user equipment identifier; and in response to the receiving, performing a registration from the relay user equipment with the network node, the registration comprising an association between the remote user equipment and the relay user equipment.)
1. A method for Internet Protocol (IP) multimedia subsystem (IMS) communication registration by a relay user equipment, the method comprising:
receiving, at the relay user equipment, an association message from a remote user equipment, the association message containing a remote user equipment identifier; and
in response to the receiving, performing a registration with a network node from the relay user equipment, the registration comprising an association between the remote user equipment and the relay user equipment.
2. The method of claim 1, wherein the association message is a SIP registration.
3. The method of claim 1, wherein performing the registration comprises: sending a registration message to a network node associated with the relay user equipment.
4. The method of claim 3, wherein the registration message includes one or more indications selected from a group of indications comprising: a relay user equipment identifier; an indication that the relay user equipment is acting as a relay; the remote user equipment identifier; and an application server identifier.
5. The method according to claim 4, wherein the network node provides functionality for at least one of: a serving call session control function; a proxy call session control function; interrogating a call session control function; or an application server.
6. The method of claim 4, wherein the one or more indications are provided in a feature tag.
7. The method of claim 3, further comprising: receiving, at the relay user equipment, a subscription message from the network node requesting notification of a change in resource status on the relay user equipment.
8. The method of claim 1, further comprising: after receiving the association message, providing a response to the remote user device, the response providing information to allow the remote user device to perform additional registrations with network nodes associated with the remote user device.
9. The method of claim 8, wherein the information provided in the response includes one or more of: an identifier for the relay user equipment, capabilities of the relay user equipment, and an application server identifier.
10. The method of claim 9, wherein the capabilities comprise one or more indications selected from a group of indications comprising: microphone availability; speaker availability; video availability; and audio availability.
11. The method of claim 9, wherein the application server identifier identifies a resource manager and may include an identifier selected from the group of: a fully qualified domain name; a uniform resource identifier; unifying resource names; and an IP address.
12. A relaying user equipment for Internet Protocol (IP) multimedia subsystem (IMS) communication registration, the relaying user equipment comprising:
a processor; and
a communication subsystem for performing communication between a mobile station and a mobile station,
wherein the relay user equipment is configured to:
receiving an association message from a remote user equipment, the association message containing a remote user equipment identifier; and
in response to receiving the association message, performing a registration with a network node from the relay user equipment, the registration comprising an association between the remote user equipment and the relay user equipment.
13. The relaying user equipment of claim 12, wherein the association message is a SIP registration.
14. The relay user equipment of claim 12, wherein the relay user equipment is configured to perform the registration by sending a registration message to a network node associated with the relay user equipment.
15. The relay user equipment of claim 14, wherein the registration message comprises one or more indications selected from a group of indications comprising: a relay user equipment identifier; an indication that the relay user equipment is acting as a relay; the remote user equipment identifier; and an application server identifier.
16. The relay user equipment of claim 15, wherein the network node provides functionality for at least one of: a serving call session control function; a proxy call session control function; interrogating a call session control function; and an application server.
17. The relay user equipment of claim 15, wherein the one or more indications are provided in a feature tag.
18. The relay user equipment of claim 14, wherein the relay user equipment is further configured to receive a subscription message from the network node requesting notification of a change in resource status on the relay user equipment.
19. The relay user equipment of claim 12, wherein the relay user equipment is further configured to: after receiving the association message, providing a response to the remote user device, the response providing information to allow the remote user device to perform additional registrations with network nodes associated with the remote user device.
20. The relay user equipment of claim 19, wherein the information provided in the response includes one or more of: an identifier for the relay user equipment, capabilities of the relay user equipment, and an application server identifier.
21. The relay user equipment of claim 20, wherein the capabilities comprise one or more indications selected from a group of indications comprising: microphone availability; speaker availability; video availability; and audio availability.
22. The relay user equipment of claim 20, wherein the application server identifier identifies a resource manager and may include an identifier selected from the group of: a fully qualified domain name; a uniform resource identifier; unifying resource names; and an IP address.
23. A computer readable medium for storing instruction code that, when executed by a processor of a relay user equipment for Internet Protocol (IP) multimedia subsystem (IMS) communication registration, causes the relay user equipment to:
receiving an association message from a remote user equipment, the association message containing a remote user equipment identifier; and
in response to receiving the association message, performing a registration with a network node from the relay user equipment, the registration comprising an association between the remote user equipment and the relay user equipment.
Technical Field
The present disclosure relates to methods and systems for providing connectivity for Internet Protocol (IP) multimedia subsystem (IMS) services by relaying user equipment.
Background
In many cases, multiple User Equipments (UEs) may be co-located within a small area. For example, in a vehicle, the vehicle itself may have a first UE, and each passenger within the vehicle may have multiple other UEs.
A first UE (e.g., a UE of a vehicle) may have a better data connection with a network than a portable user equipment. For example, a UE of a vehicle may have an antenna mounted on the roof that allows better signal reception than a UE of a vehicle occupant.
Further, in many cases, each of the UEs in a cell may have a separate or different IMS/Session Initiation Protocol (SIP) service provider. Such UEs may also have different Home Public Land Mobile Networks (HPLMNs), respectively, and may be associated with different visited or registered public land mobile networks (VPLMNs or RPLMNs, respectively).
Drawings
The disclosure will be better understood with reference to the accompanying drawings, in which:
fig. 1 is a block diagram illustrating a packet data network connection between a user equipment and a packet data network.
Figure 2 is a block diagram illustrating internet protocol multimedia subsystem components within a fourth generation network.
Fig. 3 is a data flow diagram illustrating simplified IMS registration.
FIG. 4 is a data flow diagram showing a Session Traversal Utility (STUN) using a Network Address Translator (NAT) and an interactive connection setup around the NAT using a relay for Traversal (TURN);
figure 5 is a block diagram illustrating a basic architecture for a remote user equipment using a relay user equipment for IMS;
FIG. 6 is a block diagram illustrating an example architecture for embodiments of the present disclosure;
figure 7 is a data flow diagram illustrating a first embodiment for registering a remote user equipment by a relay user equipment;
fig. 8 is a data flow diagram illustrating encapsulation of a SIP request/response within another SIP request/response for IMS messaging with a relaying user equipment;
figure 9 is a data flow diagram illustrating a second embodiment for IMS registration of a remote user equipment via a relay user equipment;
figure 10 is a data flow diagram illustrating a third embodiment for IMS registration of a remote user equipment via a relay user equipment;
figure 11 is a data flow diagram illustrating a relay user equipment requesting an application server identity;
FIG. 12 is a data flow diagram illustrating a first embodiment for determining whether a relay user equipment resource may be used;
FIG. 13 is a data flow diagram illustrating a second embodiment for determining whether a relay user equipment resource may be used;
FIG. 14 is a data flow diagram illustrating a third embodiment for determining whether a relay user equipment resource may be used;
FIG. 15 is a data flow diagram illustrating a fourth embodiment for determining whether a relay user equipment resource may be used;
fig. 16 is a data flow diagram illustrating a fifth embodiment for determining whether relay user equipment resources are available for an incoming SIP request;
fig. 17 is a data flow diagram illustrating a fifth embodiment for determining whether a relay user equipment resource may be used for an outgoing SIP request;
fig. 18 is a data flow diagram showing media routing on a relay user equipment using STUN and TURN for IMS;
FIG. 19 is a block diagram of a simplified electronic device that can be used with the methods and systems herein, according to one embodiment; and
FIG. 20 is a block diagram of a mobile device according to one embodiment.
Detailed Description
The present disclosure provides a method for Internet Protocol (IP) multimedia subsystem (IMS) communication registration by a relay user equipment, the method comprising: receiving, at the relay user equipment, an association message from the remote user equipment, the association message containing a remote user equipment identifier; and in response to receiving, performing a registration with the network node from the relay user equipment, the registration comprising an association between the remote user equipment and the relay user equipment.
The present disclosure also provides a relay user equipment for Internet Protocol (IP) multimedia subsystem (IMS) communication registration, the relay user equipment comprising: a processor; and a communication subsystem, wherein the relay user equipment is configured to: receiving an association message from a remote user equipment, the association message containing a remote user equipment identifier; and in response to receiving the association message, performing a registration with the relay user equipment from the network node, the registration comprising an association between the remote user equipment and the relay user equipment.
The present disclosure also provides a computer readable medium for storing instruction code that, when executed by a processor of a relaying user equipment for Internet Protocol (IP) multimedia subsystem (IMS) communication registration, causes the relaying user equipment to: receiving an association message from a remote user equipment, the association message containing a remote user equipment identifier; and in response to receiving the association message, performing a registration with the network node from the relay user equipment, the registration comprising an association between the remote user equipment and the relay user equipment.
In a case where multiple UEs are close to each other, one UE may have better coverage than the other UEs. As indicated above, this may be due to the configuration of the user equipment's antenna, the location of the user equipment, or other factors. Thus, in accordance with embodiments of the present disclosure, methods and systems are provided to allow sharing of a data connection of a first UE for IMS/SIP based services to other UEs, where the other UEs have separate or different IMS/SIP service providers from the first UE. Further, in some cases, the UE may have a different HPLMN and/or may have a different RPLMN or VPLMN than the first UE.
Further, in accordance with other embodiments of the present disclosure, methods and systems are provided for routing incoming and outgoing calls and/or sessions so that they may be served by one of a plurality of different UEs. The options include being served by the first UE, another device associated with the first UE (e.g., an infotainment system), or with other UEs that initiated or are directed to the call or session.
The present disclosure is described below with respect to a vehicle system, where a first UE belongs to a vehicle and other UEs belong to passengers in the vehicle or may be associated with other vehicle subsystems. However, these embodiments are provided for illustration purposes only, and in other cases, multiple user devices may be in proximity to each other and may utilize the techniques described herein. Accordingly, the present disclosure is not limited to vehicle embodiments.
Further, in the following figures, the flow of communication between functions is shown. However, those skilled in the art will appreciate that in some cases, the communication flow may be performed by intermediate entities or logical functions not shown.
In the present disclosure, the following terms have at least the meanings provided in table 1 below.
Table 1: definition of terms
Data connection
A UE wishing to use a cellular data connection or service may utilize at least one evolved Universal Mobile Telephone System (UMTS) terrestrial radio access network (E-UTRAN), an Enhanced Packet Core (EPC), and a Packet Data Network (PDN). The combination of E-UTRAN and EPC is known as Enhanced Packet System (EPS). For 5G systems, this includes one or both of Next Generation (NG) radio and NG core networks.
Reference is now made to fig. 1. In the example of fig. 1, UE110 is connected with PDN120 using PDN connection 122. In some embodiments, such a PDN connection may be referred to as a Packet Data Protocol (PDP) context in second generation (2G) or third generation (3G) networks, or as a Packet Data Unit (PDU) session in fifth generation (5G) networks. The PDN connection 122 may be used to transmit and receive data, such as signaling or control plane data, user plane data, voice/audio media, video media, and other data options, between the UE110 and the
As provided in fig. 1, the PDN connection 122 is typically located on the E-UTRAN 132 and the
E-UTRAN 132 and EPC134 typically, but not always, belong to a mobile network operator or cellular operator, while PDN120 may belong to an operator or other entity. For example, a PDN may belong to a corporate or enterprise network.
The
The
The PDN connection 122 provides a path for data between the UE110 and the
The APN consists of Network Identity (NI) and Operator Identity (OI) parts as defined in the third generation partnership project (3GPP) Technical Specification (TS)23.003 "number, addressing and identification", e.g. as provided in v.14.3.0 of 3 months 2017. The NI and OI portions are each composed of strings separated by dots. The characters between the dots are called "labels".
In one embodiment, the content of the NI portion may be undefined, while the content of the OI portion is strictly defined. The OI portion is typically appended by the network to the end of the NI. Network nodes that may perform this function include, but are not limited to, Serving GPRS Support Nodes (SGSNs), MMEs, S-GWs, P-GWs, and the like.
In other embodiments, if the UE wishes to specifically request interruption of the PDN in a particular Public Land Mobile Network (PLMN), and in case the UE does not provide OI, the UE may provide both NI and OI, and the network uses defined logic to decide to append OI to NI. This defined logic may be found, for example, in 3GPP TS 23.060 "General Packet Radio Service (GPRS); service description; stage 2 ", such as provided in v.14.4.0 of 6 months 2017.
The UE is roaming when it is not attached to a PLMN that is its home PLMN or extended hplmn (ehplmn). When the UE roams, the PDN connection may be connected to a PDN in a VPLMN or HPLMN. The connection with the PDN in the VPLMN is sometimes referred to as "local breakout" (LBO). The connection to the PDN in the HPLMN is sometimes referred to as "home routing" or "S8 interface home routing" ("S8 HR").
A UE may have more than one PDN connection if the UE needs to connect to more than one PDN. A PDN connection consists of one or more EPS bearers (which may be referred to simply as "bearers") for transmitting and receiving data between the UE and the network. One EPS bearer within a PDN connection is considered a "default bearer" or "default EPS bearer" and is typically created when the PDN connection is established. The remaining EPS bearers other than the default EPS bearer are referred to as "dedicated EPS bearers" or simply "dedicated bearers" and are used to provide different quality of service (QoS) for data from the default EPS bearer.
Each EPS bearer has a QoS Class Identifier (QCI). A complete list of QCIs may be found, for example, in subclause 6.1.7.2 "Policy and changing control architecture" of 3GPP TS23.203, such as provided in v.14.4.0 of month 6, 2017. In some embodiments, other information than QCI, such as traffic flow templates, may be used to determine which data crosses which EPS bearer.
In some embodiments, a UE may be configured, pre-configured, or provisioned with an APN for different services, features, or functions. In other embodiments, a "known" APN may be used in addition to or instead of such a supplied APN. A known APN is an APN whose value is standardized or specified as a specific value. An example of a known APN is the "IMS known APN", also referred to as "IMS APN" in some documents. Some IMS-based services deployed by the HPLMN use APN connectivity with APNs known to the IMS.
Details of IMS-known APNs are defined, for example, in the global system for mobile communications (GSM) association permanent reference (GSMA) ir.88 "LTE Roaming Guidelines" v.9.0,
The UE establishes a PDN connection with an APN known to the IMS, ensuring that the default EPS bearer used for this PDN connection has a specific QCI value of "5" which is appropriate for the signaling messages defined in 3GPP TS 23.401 "General Packet Radio Service (GPRS) enhancements for Evolved Universal Radio Access Network (E-UTRAN) Access", such as provided in v.15.0.0 and 3GPP TS23.203 of 6 months of 2017. The UE may then establish one or more dedicated EPS bearers for voice/audio and video media as needed with QCI values of one and two, respectively. A PDN connection with an APN known to IMS may be referred to as an IMS PDN connection.
Although the value of APN known by IMS is standardized, IMS PDN connections provide connectivity to the HPLMN of the UE or PDN in VPLMN of the UE. That is, if another UE has a different HPLMN and/or is attached to a different PLMN, the PDN connected by one UE may be different from the other UE, which may depend on whether the UE is roaming. For example, a UE may have different Subscriber Identity Modules (SIMs), Universal Subscriber Identity Modules (USIMs), or IMS Subscriber Identity Modules (ISIMs).
IMS
Referring now to fig. 2, an overview of an IP multimedia (core network) subsystem is shown. The IMS network may, but need not, be attached to a fourth generation (4G) network or a fifth generation (5G) network and may be made up of a number of functional elements, a subset of which is described below with respect to fig. 2.
In particular, the
Communication between the
Serving call session control function (S-CSCF)230 processes sessions in the network and routes SIP messages to the appropriate IMS Application Server (AS) and P-CSCF. S-
An interrogating call session control function (I-CSCF)240 is used as an entry point to find the subscriber in the network and to assist in assigning the S-
AS 250 typically provides service-specific functionality. Examples of ASs may include telephony application servers, which are typically used to provide service logic and control for telephony services, such AS voice/audio or video. Another example of an AS may be a service centric and continuity AS, which is typically used to provide service logic and control for centralizing services between a Circuit Switched (CS) in the IMS and the IMS, and exchanging SIP sessions and their associated media between UEs and/or across different IP networks.
In one embodiment, AS 250 may be an IMS application server. Such IMS application servers have logic and software to execute services for IMS subscribers. There may be 0 to many such application servers in the network.
The
The Home Subscriber Server (HSS)260 is a first database that contains subscriber profiles (including identities and subscribed services) and provides location functionality as well as an authentication database (second database).
A more complete description of the functionality of the above elements can be found in 3GPP TS 23.002 "Network Architecture", e.g., v.14.1.0 at 3 months 2017 and TS 23.228 "IP Multimedia Subsystem (IMS); stage 2 ", for example in v.14.4.0, 6 months 2017.
IMS registration is required so that subscribers and their UEs can use IMS-based services. The IMS registration procedure is described, for example, in 3GPP TS 23.228. In particular, subclause 5.2.2.3 provides for IMS registration and is described below with respect to fig. 3.
As seen in fig. 3, the UE310 is located in a visited network 320. The UE310 communicates with the P-CSCF312 of the visited network 320.
Further, home network 322 includes I-
The registration process includes the UE310, which UE310 sends a registration message 330 to the P-
Based on received message 332, I-
Based on
In response to
The S-
The I-
Once the UE310 has registered with the network, it can receive and send additional SIP requests/messages. The SIP request includes SIP methods, which may be, but are not limited to, those described in table 2 below.
Table 2: example SIP method
The SIP request may include a header, parameters associated with the header, and a body.
Within some SIP requests, another protocol may be included within a body called Session Description Protocol (SDP). The purpose of SDP is to convey information about media streams and multimedia sessions to assist participants in joining or collecting information about a particular session.
The Internet Engineering Task Force (IETF) request for comments (RFC)3264, "An Offer/answer model with the Session Description Protocol (SDP)" in month 6 2002 defines the SDP Offer/answer mechanism. This mechanism allows two entities to reach a common view of a multimedia session using SDP. In the model, one participant provides a description of the required conversation from their perspective to another participant, and the other participant answers the required conversation from their perspective. This offer/answer model is most useful in unicast sessions, where information from both participants is required to view the session in its entirety. The offer/answer model is used with SIP/SDP.
SDP allows a temporary participant (temporal participant) to examine information and decide whether to join a session. Further, this information allows participants to determine how and when to join the session.
The format of the entry in SDP is in the form of < type > < value >, where < type > defines a unique parameter, and < value > provides a value for that parameter. There may be multiple instances of a particular parameter.
The session description parameters include "v" which provides a protocol version, "o" which represents the owner/creator and session identifier, and "c" which represents connection information. The "c" field may provide a network type (such as the internet), an address type (such as IP version 4(IPv4) or IP version 6(IPv6)), and/or a connection address, i.e., an IP address or host to which the media packet is to be sent.
STUN and TURN
There is a Network Address Translator (NAT) function that can be co-located with a firewall function to enhance the security of the network by obfuscating the IP addresses of the nodes on the network, thus preventing these nodes from being directly reachable from nodes other than the network. However, this feature may also cause problems in real-time communications because nodes on the network cannot directly receive incoming calls, sessions, communications, conversations, and/or transactions.
A combination of approaches may overcome the obstacles posed by NAT/firewalls. For example, a combination of Session Traversal Utility (STUN) of NAT, traversal around NAT using relays (TURN), and Interactive Connection Establishment (ICE) may be used to provide a solution for real-time communication. Each is described below.
STUN provides client software on IP nodes with: the way in which its assigned address and port are learned on NATs observed from other networks than its network. For example, an IP node on the other side of the NAT may learn its assigned address and port on the NAT. STUN by itself is not sufficient to allow incoming traffic to traverse NATs due to the diversity and complexity of NAT/firewall functions.
TURN introduces a "man-in-the-middle" type server that relays, proxies or transports IP data traffic on behalf of the client behind the NAT, thereby allowing the client to be reachable from the other end of the NAT. The TURN server relays traffic between two communication points. Specifically, the TURN protocol is defined in IETF RFC 5766 "Relay Using Relay around NAT (TURN): Relay Extensions to Session Transmission Utilizations for NAT (STUN)" at 4.2010. The TURN protocol is an extension of STUN and most TURN messages are formatted identically to their STUN equivalent.
According to IETF RFC 5766 section 1, "[ TURN ] clients may arrange servers to relay packets to and from some other host (referred to as a peer host) and may control aspects of how the relay is accomplished. The client accomplishes this by obtaining the IP address and port (called the relay transport address) on the server. When a peer sends a packet on the relay transport address, the server will relay the packet to the client. When the client sends the data encapsulation to the server, the server relays the data encapsulation to the appropriate peer using the relayed transport address as the source. "
ICE is defined in IETF RFC 5245 "Connectivity Establishment protocol (ICE): A protocol for Network Address Translator (NAT) transaction for Offer/Answer Protocols", 4.2010. The specification provides a technique of how STUN and TURN can be used with SIP and SDP to establish a session when NAT is used between SIP endpoints. ICE enhances SDP to provide a way to communicate with candidate IP addresses discovered using STUN and TURN, and negotiates between User Agents (UAs) candidate pairs of IP addresses that may be used to exchange media. With respect to fig. 4, an example is shown where ICE uses STUN and TURN to establish a session via NAT using SIP/SDP.
Referring to fig. 4, the STUN/
Further, the
The STUN/
In response to
Based on the stored binding,
Subsequently, TURN messages are exchanged. Specifically, in message 430, the STUN/
In response to receiving
The
A keep-
The STUN/
The
Using the embodiment of fig. 4, a SIP session may be established for a client behind a NAT.
ProSe Relay UE- "UE-to-network Relay"
Proximity services (ProSe), for example as in 3GPP TS 23.303 "Proximity-based services (ProSe); stage 2 ", such as provided in v.15.0.0 at 6 months 2017, defines a feature set that a first UE (e.g., a remote UE) may discover other UEs when the first UE does not have cellular coverage (e.g., E-UTRAN coverage). To achieve this, the first UE is provisioned with a set of radio parameters that allow the first UE to perform sidelink/PC 5/PC5 sidelink device-to-device (D2D) communication, which is basically the way the first UE can communicate with another UE. The first UE then uses the radio parameters to configure the radio to broadcast or listen on frequency, which helps the first UE find another UE with which to communicate. Another UE with which the first UE may communicate may be referred to as a "UE-to-network relay. A "UE-to-network relay" is a UE that has a connection with the E-UTRAN and one or more other UEs, and can relay traffic between the connected E-UTRAN and the one or more other UEs. The "UE-to-network relay" may also be referred to as a relay UE. Relay UEs may also be described as a function of receiving and sending communications via a first Radio Access Technology (RAT), and sending/forwarding and receiving these communications or a subset of these communications via a second RAT, where the first and second RATs may be the same and communications on the first and second RATs may or may not occur simultaneously.
The UE knows that the message received over the sidelink is for a certain ProSe application based on the destination tier two ID used for the message. This functionality is provided, for example, in 3GPP TS 23.285 "Architecture enhancements for V2X services", such as provided in v.14.3.0, 6 months 2017. The layer 2ID code point value is not defined in the 3GPP specifications, but is left to be selected by the operator community. However, the second layer ID may be configured within the UE.
Registration and SIP signaling
With the above infrastructure, in embodiments of the present disclosure, the relay UE acts as an IMS/SIP proxy for each remote UE that is somehow locally connected to the relay UE. This approach is referred to herein as a local connection. Then, using the local connection, the relay UE may provide the SIP session to the remote UE.
As used herein, a "relay UE" is a device that has its own data connection and can share that data connection to other devices. In some cases, such a relay UE may be associated with a vehicle, but in other cases, the relay UE may be provided in a non-vehicle application. In some cases, the relay UE may also be referred to as a vehicle-to-recipient (V2X) module.
Further, a SIP proxy is a functional or logical entity that may act as one or both of a server and a client for the purpose of receiving and issuing SIP requests on behalf of other clients. The SIP proxy receives the SIP request and may modify the contents of the SIP request prior to proxying the SIP request. However, the identifier used to uniquely identify a SIP session is typically not modified. In the context of the present disclosure, the SIP proxy may be replaced by a back-to-back user agent (B2 BUA). The B2BUA typically terminates the first incoming session/conversation and initiates the second session/conversation using one or more data items obtained from the first incoming session/conversation in the initiated second session/conversation. The definition of IETF RFC 3261 "SIP: Session initiation Protocol" from 6.2002 also applies. Such definitions include:
proxy, proxy server: an intermediate entity acting as a server and a client for the purpose of issuing requests on behalf of other clients. The proxy server acts primarily as a route, meaning that it works to ensure that requests are sent to another entity "closer" to the target user. The agent is also useful for enforcing policies (e.g., ensuring that the user is allowed to make a call). The proxy interprets and, if necessary, rewrites certain portions of the request message before forwarding the request message.
Back-to-back user agents: a back-to-back user agent (B2BUA) is a logical entity that receives a request and handles it as a User Agent Server (UAS). To determine how the request should be answered, it acts as a User Agent Client (UAC) and generates a request. Unlike a proxy server, it maintains the session state and must participate in all requests sent on the session it has established. Since it is a concatenation of UAC and UAS, its behavior does not need to be explicitly defined.
Referring to fig. 5, a
The
In one embodiment, the WAN connection may utilize a PDN connection (e.g., over LTE radio access technology) or a PDU session (e.g., over 5G radio access technology) with the HPLMN residing at the remote UE, the HPLMN of the relay UE, or the VPLMN of the relay UE. In all cases, Network Access Stratum (NAS) signaling and procedures are not affected.
The
Once the
Referring now to fig. 6, an example architecture that may be used with respect to embodiments of the present disclosure is shown. However, the architecture of fig. 6 is provided as an example only, and other architectures are possible.
In the example of fig. 6, the
Further,
The P-
In the embodiment of fig. 6, traffic routed for the
Such traffic may then be routed to
Traffic from the S-
The traffic may then be routed to the
According to the embodiments described below, one of the following two operation modes may be used. In a first mode of operation, the relay UE may act as a layer 2 relay. This means that the remote UE has a first IP address and the relay UE has a second IP address. For SIP requests containing SDP offers and/or SDP answers, the connection data line may have the IP address of the UE for which the media is intended. Thus, the IP address may be the first IP address or the second IP address.
In the second mode of operation, the relay UE may act as a NAT. Thus, the relay UE maintains a state to which incoming media and SIP requests are to be routed. In order to do this when a SIP request is received at the relay UE, the relay UE needs to remember whether such messages should be routed to the remote UE. If the remote UE receives a SIP control message and the sequence of messages arriving at the remote UE results in a session establishment, then media is routed to the remote UE. Otherwise, the media is terminated at the relay UE.
In practice, relay UEs host STUN and/or TURN servers, while remote UEs host STUN and/or TURN clients. This functionality is provided below.
In the embodiments described below, both registration and SIP messaging are described.
First mechanism for IMS registration
According to a first embodiment of the present disclosure, a remote UE performs IMS registration with a home IMS of the remote UE via the home IMS of the relay UE using the relay UE. In particular, the home IMS is the IMS of the HPLMN of the UE. Further, in one embodiment, registration may optionally be via an IMS relaying access of the UE. In other words, the visited IMS is the IMS of the VPLMN to which the remote UE is currently attached. The registration is for IMS related signaling and media.
The relay UE acts as a back-to-back user agent (B2BUA) and media gateway with some enhancements to SIP. In particular, the SIPB2BUA functionality terminates and re-sends all SIP messaging between the remote UE and the P-CSCF of the relay UE. Further, when the remote or relay UE acts as a media gateway, the remote or relay UE terminates the media received from the network and then the UE relays it to the other side. As used herein, a media gateway may be any functional or logical entity that may convert a media stream.
Enhancements include, but are not limited to, including an indication that SIP/IMS registration is for the remote UE in order to prevent IMS deregistration of the relay UE. For remote UEs, the relay UE may appear to be a P-CSCF, however, when the messaging arrives at the relay UE, the relay UE may perform the functions of a B2BUA or a SIP proxy. Further, the relay UE may appear to the remote UE as a P-CSCF to the IMS of the remote UE.
The relay UE may use either the visited IMS or the home IMS. The respective usage may depend on whether the relay UE utilizes a PDN (which may be referred to as S8HR) in the relay UE' S home network or a PDN (which may be referred to as LBO) in the network visited by the relay UE.
By utilizing the relay UE's IMS connection with its visited or home IMS, and by including an indication that the registration is for the remote UE, the remote UE can use the relay UE's IMSPDN connection and provide full visibility to the relay UE's IMS signaling access network and subsequently used IMS data. This in turn allows the quality of service or quality of experience to be applied to IMS calls or sessions. Further, it allows the relay UE to serve or terminate incoming or outgoing sessions, which is useful when the relay UE is an infotainment system, e.g. in a vehicle.
Reference is now made to fig. 7. The embodiment of fig. 7 shows a remote UE 710 in communication with a relay UE 712. Further, the IMS of the relay UE is shown with block 714 and the IMS of the remote UE is shown with block 716. In some embodiments, the IMS of the relay UE and the IMS of the remote UE may be the same IMS.
According to the embodiment of fig. 7, relay UE712 registers with the relay UE's IMS 714, as shown in block 720. Registration at block 720 uses a standard IMS registration procedure over the relay UE's IP connection with the relay UE's IMS. The IP connection of the relay UE to the IMS of the relay UE may be through a PDN connection, and the PDN connection may be a PDN connection with the IMS APN using LBO or S8 HR.
As part of the registration in block 720, the relay UE712 may include an indication of the relay UE's IMS 714: the relay UE wishes to assume the role or function of the relay UE, e.g., as described herein in various embodiments in this disclosure. The remote UE may further receive an indication from the IMS 714 of the relay UE: the relay UE is permitted to assume the role or function of the relay UE. The message indicating that the relay UE is permitted to assume this role may be due to a request to become a relay, or may be unilaterally sent by the relay UE's IMS 714.
Subsequently, the remote UE 710 wishes to register for SIP services with the relay UE 712. In this case, remote UE 710 sends SIP register message 730 to relay UE712 via the local connection.
In response to receiving SIP register message 730, relay UE712 uses the information from message 730 to create or construct a new SIP register. Relay UE712 may then perform one or more of the following.
In a first embodiment, the relay UE may exchange, replace, or swap some or all instances of the IP address of the remote UE with its own IP address or addresses. In other words, at block 720, the IP address from the interface used by the remote UE to connect locally with the relay UE may be swapped with the IP address of the interface used by the relay UE712 to perform the registered relay UE.
In a second embodiment, relay UE712 may add or include a relay UE indication to the SIP register. Such an indication may be a SIP header, a SIP header option, a SIP request XML body, and other options. The relay UE indication may be used to inform the IMS 716 of the remote UE that the SIP registrar is the SIP registrar being relayed. In other words, the SIP register does not originate from relay UE 712.
In a third embodiment, the relay UE may exchange, replace, or swap out some or all instances of the International Mobile Equipment Identifier (IMEI) of the remote UE with its own IMEI. The relay UE712 may also include an indication of the IMEI of the remote UE. This may be done, for example, in the SIP header, in the XML body of the SIP register, and in other options.
In some embodiments, the three actions provided above for relay UE712 may be used independently, or may be combined in various combinations.
Relay UE712 then forwards, proxies, or sends the new SIP register to an entity on IMS 714 of the relay UE. Such an entity may be any node, host, SIP server or SIP proxy in the IMS of the relay UE and may include, for example, a P-CSCF, an I-CSCF, an S-CSCF, among other options. This message may be forwarded as shown by message 732 in the embodiment of fig. 7, and may result in the third party registration being sent to the application server.
The relay UE712 also creates a binding between the remote UE and the SIP register of the IMS 714 sent to the relay UE to ensure that the received response to the SIP register can be relayed or proxied to the correct remote UE 710. Bindings may include, but are not limited to, the following:
if the same call ID is included in the SIP registration of IMS 714 sent to the relay UE, then relay UE712 binds the call ID included in the SIP registration received from remote UE 710 to one or more identities of the remote UE used on the local connection, e.g., the IP address of the remote UE used on the local connection, the MAC address belonging to the remote UE used for the local connection, the MAC address belonging to the relay UE used on the local connection, etc.
If a different call ID is included in the SIP registration sent to the relay UE's IMS 714, then the relay UE712 binds the call ID included in the SIP registration received from the remote UE to the call ID included in the SIP registration sent to the relay UE's IMS, and optionally also to one or more identities of the remote UE used on the local connection, e.g., the IP address of the remote UE used on the local connection, the MAC address belonging to the remote UE for the local connection, the MAC address belonging to the relay UE used on the local connection, and other options.
In response to receiving the SIP register from the relay UE712, the node on the relay UE's IMS 714 may perform authentication: the relay UE712 is allowed to perform the function or role of the relay UE. This check may be made based on the relay UE indication received in the SIP register message. If a check is performed and the relay UE is unable to perform or is prohibited from performing the role of relay UE, an error response may be sent back to the relay UE 712.
However, if the check is performed and the relay UE712 is allowed to perform the role of relay UE, or if the check is not performed in some embodiments, the same node or a different node of the relay UE's IMS 714 may perform the following two operations. The IMS 714 of the relaying UE may add the indication of the relay to the SIP register message. Such a relay indication may be made by modifying the same field or information element as the relay UE indication in message 732. For example, the SIP header, SIP header options, SIP request body XML, and other options may be changed at the IMS of the relay UE. Alternatively, the information may be added as a new field or information element in the SIP register message, and may be added as a SIP header, a SIP header option, a SIP request body XML, and other options.
In addition to the add indication, the IMS 714 of the relay UE may forward the received SIP register message 732, including the modification, to a node in the IMS 716 of the remote UE. Such nodes may include, but are not limited to, P-CSCF, I-CSCF, S-CSCF, AS, and other options for remote UE 710. The SIP register message is sent from the relay UE's IMS 714 to the remote UE's IMS 716, as shown by message 734. For example, in 3GPP TS24.229, "IPmultimedia call controlled Protocol based on Session Initiation Protocol (SIP) and Session Descriptionprotocol (SDP); the standard procedure defined in Stage 3 "sends this message, for example as provided in v.14.3.1 of month 3, 2017.
In response to receiving the SIP register from the IMS 714 of the relay UE, the node in the IMS 716 of the remote UE may perform an authentication or check: the remote UE is allowed to use the relay UE712, which may be performed due to the reception of the relay indication in the SIP register message. If a check is performed and the relay UE's use is disabled, an error response (such as, but not limited to, a "403 disable" response) may be sent to the relay UE's IMS 714.
Conversely, if the check is performed and the remote UE 710 is allowed to use the relay UE712, or if the check is not performed, the same or another node in the IMS 716 of the remote UE may process the SIP register with standard procedures. For example, authentication may be performed in a security challenge and an unauthorized response of
In response to receiving the SIP response from the IMS of the remote UE, the IMS 714 of the relay UE then forwards the received SIP response to the relay UE712 using standard procedures such as defined in 3GPP TS 24.229. This forwarding is illustrated in the embodiment of fig. 7 by message 742.
In response to receiving the SIP response from the relay-UE's IMS 714, the relay-UE 712 may perform a lookup in a binding store (e.g., created before sending the above message 732) for the call ID of the SIP response received from the relay-UE's IMS 714.
If the lookup is successful and thus finds that the remote UE is bound to the call ID of the received SIP response, the relay UE712 uses information from the response to create a new SIP response and may perform one or more of the following. In a first embodiment, relay UE712 may exchange or swap out some or all instances of its own IP address with the IP address of the remote UE. Thus, relay UE712 may swap the IP address of the interface of the remote UE that the remote UE uses to perform SIP registrar. Additionally or alternatively, relay UE712 may add the relay UE indication (e.g., as a SIP header, SIP header options, SIP request XML body, and other options) to a SIP register to inform remote UE 710: the SIP response is being relayed and therefore does not originate from the relay UE 712.
The relay UE712 then forwards the new SIP response to the remote UE 710 in message 744.
The remote UE 710 may then perform standard security procedures, e.g., as described in 3gpp ts33.203 "3 g security; access security for IP-based services ", such as provided in v.14.0.0 of month 3, 2017, and create a new SIP register message 750. Message 750 may contain a security challenge response generated by remote UE 710 based on 401 unauthorized message 744. Message 750 is then sent to relay UE 712.
Relay UE712 may then perform similar functionality as SIP register message 730. Specifically, relay UE712 sends a SIP register message 752 to relay UE's IMS 714.
The relay UE's IMS 714 may then perform similar functionality as it did when receiving message 732 when receiving message 752. The IMS 714 of the relaying UE may forward the SIP register message to the IMS 716 of the remote UE in a SIP register message 754.
In response to receiving message 754, IMS 716 of the remote UE may perform verification that the remote UE is permitted to use the relay UE, which may be caused by receiving the relay indication in the SIP register. If a check is performed and the relay UE is prohibited from being used, an error response may be sent to the relay UE's IMS 714. Such an error response may be, for example, a "403 inhibit" response.
If a check is performed and the remote UE 710 is allowed to use the relay UE712, or if no check is performed, e.g. because the check has been performed in a previous step, the same or another node of the IMS 716 of the remote UE may process the SIP register according to standard procedures. For example, the message may perform authentication using the received security stop response and may then send a SIP 200OK message 760 back to the IMS 714 of the relaying UE.
Upon receiving message 760, the IMS 714 of the relay UE may perform similar functionality as it did upon receiving message 740. The relay UE's IMS sends a message 762 back to the relay UE712 with a 200OK indication.
Relay UE712 may then perform similar functionality as it did when receiving message 742. In addition, the relay UE may create a binding between the IMS/SIP public user identity of the remote UE (e.g., included in the P-associated URI SIP header of the received 200OK SIP response), and one or more identities of the UE on the interface between the remote UE 710 and the relay UE 712. For example, such binding may use the IP address of the remote UE, the MAC address of the relay UE used by the interface of the remote UE, and other options used on the interface between the remote UE and the relay UE. This binding may then be used to relay any SIP related messaging from the IMS 716 of the remote UE to the remote UE 710 for the duration of the remote UE's registration with the IMS 716 of the remote UE.
The relay UE712 may then send a 200OK message 764 to the remote UE 710.
Based on fig. 7, the remote UE 710 is now registered with its IMS 716 via the relay UE712 and relay UE's IMS 714, and the remote UE 710 can send and receive outgoing calls or sessions.
When the remote UE performs deregistration to the IMS 716 of the remote UE, the relay UE712 may then remove the binding created above after receiving message 762.
The embodiment of fig. 7 may be performed for additional remote UEs connected through a local connection, via the same or different relay UEs.
The binding performed by relay UE712 upon receipt of the SIP register message may also or alternatively use one or more pieces of information associated with the local connection, such as interface ID, MAC address, IP address, port number, and other options.
The binding may further include information about the remote UE including an IMS private user identity (IMPI), one or more IMS public user Identities (IMPUs), a SIP Uniform Resource Identifier (URI), a phone URI, a sequence number, an IMEI, and other options.
Package with a metal layer
In various registration and media transport embodiments described below, encapsulation of SIP messaging is provided. Thus, according to one embodiment, a generic tunneling or encapsulation process is provided.
In particular, the present disclosure provides embodiments in which a generic tunneling process is described that shows how a remote UE can send and receive SIP requests and their responses with a relay UE, where the relay UE sends the SIP request and response in a second SIP request. The application server receives the tunnelled or encapsulated message and performs similar functionality as the relay UE.
Reference is now made to fig. 8. In fig. 8,
In the example of fig. 8, S-CSCF818 receives the incoming SIP request in message 820 and forwards the incoming SIP request to AS 816 in
The second SIP request may also contain various indications for the recipient of the encapsulated SIP request. In particular, the indication may provide a second SIP request that includes the encapsulated first SIP request. The indication may further provide an address of a party that should receive the first SIP request. Further, the encapsulated second SIP method may include a transaction identifier, wherein the transaction identifier is used to identify the sender of the first SIP request, the recipient of the SIP request, and/or the first SIP method dialog.
For example, table 3 below shows an example of a feature tag for a transaction identifier.
TABLE 3-example feature tags for transaction IDs
The encapsulated incoming SIP request in the second SIP request may then be sent from AS 816 to relay UE812 in
Relay UE812 receives a second SIP request encapsulating the first SIP request from AS 816 or S-
The user agent client is a logical entity that creates a new request and then uses the client transaction state mechanism to send the request. The role of the UAC persists only for the duration of the transaction. In other words, if a software initiates a request, the software acts as a UAC for the duration of the transaction. If a request is subsequently received, it will assume the role of a user agent server for processing the transaction.
A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. The role only persists for the duration of the transaction. In other words, if some software responds to a request, the software acts as a UAS for the duration of the transaction. If a request is subsequently generated, it assumes the role of a user agent client for processing the transaction.
A User Agent (UA) is a logical entity that can act as a user agent client and a user agent server.
Relay UE812 may then extract the first SIP request from the second SIP request and send the first SIP request to
Based on the receipt of the
The relay UE812 receives the
The application server receives the SIP response encapsulated in
In another embodiment, encapsulation may be performed on SIP requests originating from the
The relay UE812 then encapsulates the first SIP request into a second SIP request. The second SIP request may contain an indication to indicate that the second SIP request contains the encapsulated first SIP request. Further, the encapsulated message may contain the address of the UE or user agent sending the first SIP request. Further, in some embodiments, the encapsulated message may include a transaction identifier, where the transaction identifier is used to identify the destination user agent, the user agent that originated the SIP request, and the dialog from the first SIP request.
In the embodiment of fig. 8, the encapsulated SIP request is sent in
At the
The SIP process may then be completed, as indicated by
At AS 816, the SIP response is received and encapsulated in a new SIP response (e.g., 18x, 2xx, etc.) to
The relay UE812 receives the encapsulated SIP response and may use the indication: such as the fact that the response contains the encapsulated SIP response, the addresses of the originator and destination parties, and the transaction identifier, to extract the SIP response from the encapsulated response and forward the SIP response in
The
Further, a SIP request, such as
In a further embodiment, the first SIP request or response may be encapsulated in an encrypted format to protect the contents of the first SIP request or response. An indicator may be provided to the relay UE812 or AS 816 indicating that ciphering is required.
Second mechanism for IMS registration
According to another embodiment of the present disclosure, the remote UE registers with the application server via the relay UE using a tunneling or encapsulation mechanism, which then acts on behalf of the remote UE. With this mechanism, the relay UE tunnels SIP messages between the remote UE and the application server.
In the following discussion, user identity is used. This may be a single user identity or may be a plurality of user identities. Further, the user identity may be any one or combination of a public user identity, a private user identity, an equipment identity, and other options.
Referring now to FIG. 9, an example registration process is shown. In the example of fig. 9,
According to the embodiment of fig. 9,
Thereafter,
Further, in some embodiments,
Once the S-
Next, S-
The
In particular, the third party registration message contains therein a third registration type, and the third registration type contains zero to many of the second registration types. The third registration type is the type received at
Upon receiving
In one embodiment, the
The
Further, AS shown in
AS 916 receives
AS 916 may then send a SIP registration request 948 containing the remote UE user identity, feature tag and other SIP registration parameters received in
The S-
Upon receiving 401
Within message 956, various information may be included, including the 401 response containing the authentication challenge vector. Further, the message may contain an indication that the message contains a SIP method for the
This information may further contain a SIP message R-URI obtained from the HSS and a reply to the header.
Based on the above,
The
The
Further, message 962 may contain an indication that the SIP message contains a message from
AS 916 receives message 962 and does not encapsulate or decapsulate or extract the registration message. The register message may then be sent to the S-
The S-
Based on
In the above, the local connection ID may be a layer-2 ID. Specifically, as in 3GPP TS 36.321 "improved Universal Radio Access (E-UTRA); the destination layer 2ID as defined in Medium Access Control (MAC) protocol specification "may be allocated to IMS applications through a vehicle-to-destination (V2X) or PC5 sidelink interface, such as provided in v.14.2.1 of 4 months 2017. The IMS data part will be transmitted as V2X information over the Physical Sidelink Shared Channel (PSSCH) and contains the corresponding IMS message. For example, the layer 2ID may be configured in an internal memory of the mobile device using Open Mobile Alliance (OMA) Device Management (DM) or stored on the USIM or ISIM.
Table 4 below shows an example where there is a layer 2ID for the SIP control message and another layer 2ID for the user plane. This information has been stored in the UE-to-network relay and the remote UE. When the remote UE receives the PC5 message, it can use checking the layer 2ID to determine that it is an IMS message
Table 4: example configuration information for defining a layer 2ID
In Table 4 above, example configuration information for 3GPP TS 31.102 "Characteristics of the Universal Subscriber Identity Module (USIM) application" is provided, for example, in v.14.2.0, 3 months 2017. The contents of table 4 are inserted into the present specification. However, table 4 provides only one example of a layer 2ID, and other options are possible.
Further, a specific ITS application identifier may be assigned to SIP requests, for example in European Telecommunications Standards Institute (ETSI) TS 102965 "Intelligent Transport Systems (ITS); application ObjectIdentifier (ITS-AID); registration list ", for example as provided in v.1.3.1 of
Table 5: ITS application identifier
Further, the SIP method identifier may be defined as a specific message type to be communicated as part of the ITS Packet Data Unit (PDU) header. One possible implementation is shown for table 6 below.
Table 6: extracting ETSI TS 102894-2
Example changes to the description are shown in bold in the example of table 6. In this way, SIP requests/responses will coexist with different or other ITS/V2X messages on a given interface and can be used simultaneously as part of different services.
Third mechanism for IMS registration
In further embodiments, the remote UE performs registration with the relay UE, causing the relay UE to perform IMS registration or re-registration with an IMS visited by the relay UE or a home IMS of the relay UE. The registration or re-registration indicates an association with the remote UE, which in turn results in a third party registration with the conflict handling server. For example, such a collision handling server may be used to manage access to microphone or speaker resources in a vehicle. The conflict handling server may be implemented AS an Application Server (AS).
This registration has the purpose of binding the relay UE with the associated remote UE. The remote UE may then perform its own registration with the home IMS of the remote UE, which in turn results in a third party registration with the collision handling server.
As will be appreciated by those skilled in the art, whether the relay UE uses visited IMS or home IMS may depend on whether the relay UE utilizes PDN (sometimes referred to as S8HR) in the relay UE 'S home network or PDN (sometimes referred to as LBO) in the relay UE' S visited network.
Reference is now made to fig. 10. In the embodiment of fig. 10, the remote UE 1010 communicates with the relay UE 1012. Further, the S-CSCF1014 of the remote UE and the S-CSCF 1016 of the relay UE are both located on the network. In some embodiments, S-CSCF1014 and S-CSCF 1016 may be the same entity. Further, an application server 1018 is provided within the network that may provide call collision handling functionality. The call conflict handling function/server manages access resources such as e.g. microphones, loudspeakers, hosts, visual display units in devices (e.g. vehicles) which may be used for the purpose of supporting only one call/session at a time.
As shown by message 1020 in the embodiment of fig. 10, the remote UE 1010 performs a first registration procedure with the relay UE 1012. In some embodiments, this first registration process may also be associated, for example, with BluetoothTMTechnology or other short-range wireless or wired technology. Message 1020 may contain a remote UE userAt least one of an ID and/or a layer 2 ID.
After receiving the message 1020, the relay UE1012 provides an acknowledgement including the relay UE's ID, its capabilities, and the application server identifier. It is provided back to the remote UE in message 1022.
The application server identifier is an identifier of a server or function responsible for managing certain capabilities on the relay UE. Such functionality may include, for example, call collision handling.
The identity of the function responsible for managing the above-described capabilities may be at least one of a user ID, a Fully Qualified Domain Name (FQDN), a Uniform Resource Identifier (URI), a Uniform Resource Name (URN), an IP address, and other options. For example, the identity may have been configured in a Mobile Equipment (ME) or a Universal Integrated Circuit Card (UICC).
An example of how the identity of the application server is encoded as a feature tag for the application server ID is shown below with respect to table 7.
Table 7: example feature tags for application Server IDs
Further, the capability of the relay UE may be a "ProSe relay service code," where the ProSe relay service code defines a set of capabilities, such as microphones, speakers, displays, and other options. The relay UE user ID may be a layer 2ID, a SIP URI, or a telephone URI.
The capabilities provided in message 1022 may be one or more indications such as, but not limited to, microphone availability, speaker availability, visual display availability, video availability, or voice/audio availability.
The relay UE1012 further sends a second registration message containing at least one of the following indications: (a) the registration is for relay UE 1012; (b) capabilities of relay UEs such as microphone, speaker, display, and other options; and/or (c) a remote UE 1010 user identifier. The second registration message may further include an implicit or explicit indication that the relay UE1012 is acting as a relay. For example, feature tags such as those provided in table 8 below may be used.
Table 8: example feature tags for Relay indications
Further, the remote UE user ID may be provided in a feature tag. An example showing a feature tag for a user ID of a remote UE is shown in table 9 below.
Table 9: example feature tags for remote UE user IDs
A second registration of the relaying-UE S-CSCF 1016 is shown with arrow 1030.
After receiving the second registration during the second registration of arrow 1030, the S-CSCF 1016 of the relaying UE may then perform a third party registration, which includes the second registration message. The third party registration is then performed with application server 1018, as indicated by arrow 1032. If not, such third party registration will occur. For example, if the application server ID is included in the second registration, the third party registration is sent to the provided address. Further, if, for example, a P-Asserted-Service is used, urn: urn-7:3 gpp-service.im.relay-app-id based on the configuration information in the S-CSCF 1016, the S-CSCF 1016 sends a third party registration to the configured address of the AS associated with the configuration information.
Alternatively, the filter criteria (as defined in 3GPP TS 24.229) may have the first application server address therein. In this case, the third party registration is sent to the AS. After receiving the third party registration, the first AS determines that the received data includes an application server ID for the second AS. The first AS may then send a registration message containing the third party registration to the second AS.
After the third party registration of arrow 1032, subscription information may be provided between the relay UE1012 and the AS 1018, AS illustrated by arrow 1034. Such subscription messaging may include relay UE capability status. Specifically, the subscription message may be sent to the relay UE 1012. The subscription message may request notification of a change in status of a resource, such as a microphone being used or idle. The relay UE1012 will typically send a 200OK message in response to the subscribe message.
AS 1018 may also create a mapping between the URI of the identity of the relay UE received in the third party registration and the remote UE, e.g. using table 5 above.
Subsequently, the remote UE may send a third registration message containing at least one of the following indications: (a) the registration is for a remote UE identified by a remote UE identifier, wherein such indication may be implicit or explicit; (b) a user ID of the relay UE; (c) a relay UE user ID and/or (d) an application server ID. This third registration message is sent as message 1040 to the S-CSCF1014 of the remote UE in the embodiment of fig. 10.
After receiving message 1040, the S-CSCF1014 of the remote UE may then perform a third party registration with AS 1018, AS illustrated by message 1042. Third party registration may involve associating the information received in message 1032 with information in message 1042 at AS 1018 to determine that message 1042 relates to message 1032. Specifically, after receiving message 1042, AS 1018 can compare the relay UE user ID (if received) with the previously received relay UE user ID, and can bind both identities if not already done. If both IDs have been bound, the AS 1018 verifies the binding.
With respect to providing application server identity in a relay UE, reference is now made to fig. 11. The embodiment of fig. 11 shows a message flow for relaying a UE request for an application server identity.
Specifically, relay UE 1112 communicates with
In response to
If
If
Table 10: example feature tags for application Server IDs
As seen in table 10 above, the address of the application server ID may be provided.
The application server may perform a number of operations, such as managing access to resources such as microphones, speakers, visual display units, etc., acting as a STUN server, acting as a TURN server, and other options. The 200OK may contain a single address that can be used for various server types, or alternatively may contain three separate feature tags. For example, three feature labels may be provided as indicated in table 11 below.
Table 11: example feature tags for application Server IDs
Thus, as indicated above, three feature tags may be provided separately.
The address may be provided in an external database such as a HSS/HLR database, policy control function, and sent via a message to a network node such as MSC, MME, P-GW, S-GW, User Plane Function (UPF), Session Management Function (SMF), S-CSCF, and other options. Such a message may for example be an insert subscriber data message according to 3GPP TS 29.002 "Mobile Application Part (MAP) specification", e.g. v.14.3.0 in 3 months in 2017 or 3GPP TS 29.272 "Evolved Packet System (EPS); mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces on diameter protocol ", such as that provided in v.14.3.0 of 3 months of 2017.
First mechanism to determine whether relay UE resources may be used
According to another embodiment, it is assumed that the registration process has already occurred. For example, the registration process of fig. 9 or fig. 10 above may have occurred.
According to this embodiment, the application server may send a tunneled or encapsulated SIP request or response to the remote UE via the relay UE. The relay UE may insert its media capabilities, such as its microphone, speaker, and other options, in the SIP request or response state. After receiving the SIP response, the remote UE determines whether media should be terminated at the remote UE or the relay UE.
Reference is now made to fig. 12. In the embodiment of fig. 12, remote UE1210 communicates with
At message 1220, the S-CSCF1218 of the remote UE receives the incoming SIP request. The S-CSCF1218 of the remote UE then forwards the incoming SIP request to the
For example, an incoming SIP request is provided in table 12 below.
Table 12: example incoming SIP method
The
The AS may then map the R-URI to a relay UE URI and/or relay UE IP address. The mapping may contain an indication of which URI is a remote UE and which URI is a relay UE.
The AS 1216 may encapsulate the SIP request into a second SIP request, e.g., a SIP message request, e.g., using the procedure of fig. 8 above. The encapsulation is shown by a second SIP request that contains an indication that it contains an encapsulated SIP request, e.g., a SIP invite. For example, the content type is set to a new content type value application, such as "vnd.3gpp.encapsulated.
The R-URI of the second message is the R-URI of
Table 13: example feature tags for remote UE IDs
In some embodiments, the encapsulated SIP request may be encrypted. In this case, a further indication may be provided that an encapsulated encrypted SIP request is provided, for example, this may be a new content type value, such as "vnd.3gpp.encapsulated encrypted"
The encapsulated SIP request is then sent as
Instead of using the implementation of the target parameters, a new feature tag may be utilized. For example, one such target parameter and/or content type is shown below with respect to table 14.
Table 14: example incoming SIP method encapsulated in SIP message
In table 14 above, the features provided in bold are highlighted to show the differences between typical SIP requests.
Once the relay UE receives the
Further, if the encapsulation is not encrypted, the SIP request may be sent over an IP transport, such as User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP).
In this embodiment, the resource may be indicated as being free by, for example, utilizing a feature tag such as described in table 15 below.
Table 15: example feature tags for idle relay UE features
Alternatively, an existing header may be used. Such a header may be, for example, a supported field with free resources that is included in the SIP method. This is shown, for example, with respect to table 16 below.
Table 16: example of an idle relay UE feature "supported header"
Conversely, if the encapsulated SIP request is encrypted, the SIP request may be sent encrypted to the remote UE. For example, the transmission may use a construct such as that described below in table 17.
Table 17: example data Structure of PC5 encrypted data
Alternatively, the local connection ID defined above with respect to fig. 9 may be utilized.
Remote UE1210 receives message 1226. It may then use the resource indication within message 1226 to determine whether
The SIP response may be, for example, a 3XX response defined in IETF RFC 3261, which 3XX response contains the relay UE user ID in the contact header field. This may be sent to relay
Conversely, if resources cannot be used at
If
Upon receiving
Encapsulation of
Upon receiving the
The AS 1216 acts AS a B2BUA for the dialog. Further, AS 1216 may include an indication that the SIP request is for remote UE1210, but should terminate at
Table 18: example feature tags for remote UE IDs
Upon receiving the
Further,
The application server may then send the message to the S-CSCF of the remote UE, i.e., S-CSCF1218, as illustrated by
The S-CSCF1218 can then send the message to the originating terminal as illustrated by
Thereafter, media is established between the originating terminal and the
Second mechanism to determine whether relay UE resources can be used
In another embodiment of the present disclosure, a check is made to determine whether relay UE resources can be used for the remote UE. The mechanism assumes that registration has occurred for the relay UE, e.g., as described above with respect to fig. 9 or 10.
According to the present embodiment, the application server determines resource availability and resource status on the relay UE. After making this determination, the application server routes the SIP request to the relay UE if the relay UE is available. Otherwise, the application server will tunnel or encapsulate the SIP request to the remote UE via the relay UE.
Referring now to fig. 13, where a remote UE 1310 and a relay UE1312 are in proximity to each other. Further, the network side includes S-CSCF 1314 of the relay UE, application server 1316, and S-CSCF1318 of the remote UE. In some embodiments, the S-CSCF 1314 of the relay UE and the S-CSCF1318 of the remote UE may be the same entity.
In the embodiment of fig. 13, the application server 1316 sends a message 1320, such as a "SIP options" method, to the relay UE1312 via the relay UE' S-CSCF 1314 to determine the capabilities of the relay UE.
The relay UE1312 receives the message 1320 and sends back an option response message 1322, the option response message 1322 containing an indication that the relay UE has, for example, a microphone, a speaker, and other options. The encoding used may be similar to that of
The application server 1316 receives the message 1322 and sends a message 1324 back to the relay UE1312 to request the status of its capabilities from the relay UE. Such a message may be, for example, a SIP subscribe message containing the at least one capability received in message 1322.
Upon receiving the message 1324, the relay UE1312 sends a 200OK response message 1326 to the application server 1316.
At some point in time, a resource, such as a microphone, becomes idle, as shown at block 1330. The relay UE1312 may then send a notification message 1332 containing an indication that the resources have been freed. The encoding may be similar to that described above with respect to message 1322.
The S-CSCF1318 of the remote UE then receives the incoming SIP request in message 1340 and forwards the SIP request to the application server 1316 in message 1342. The application server may determine, based on the status of the media capabilities, that the relay UE1312 may handle the SIP request and therefore make a selection of the contact to which to route the SIP method. In this case, the SIP request is forwarded to the relay UE1312 in message 1344. The relay UE1312 then sends a 200OK message to the AS1316 in message 1346. The AS1316 may then forward the 200OK message to the S-CSCF1318 of the remote UE in message 1348.
Thereafter, media may be established between the originating sender and the relay UE1312, as illustrated with arrow 1350.
Conversely, if the microphone is not idle when the SIP request arrives, the selection at the application server may be different. Referring to fig. 13, an incoming SIP request is provided as shown by message 1360. However, in this case, the microphone on the relay UE is not idle.
The incoming SIP request is forwarded to the application server 1316 in message 1362. The application server 1316 then encapsulates the SIP request using resources not available at the relay UE1312 to support the received SIP request and the indication of SDP. Such encapsulation may be done according to the previously described embodiments. The encapsulated SIP request is provided to the relay UE1312 in message 1364, which relay UE1312 may then un-encapsulate or de-encapsulate or extract the message and forward the SIP request to the correct remote UE. Forwarding is accomplished using message 1366.
The remote UE may then send a 200OK message 1370 back to the relay UE1312, which relay UE1312 may then encapsulate it and provide it as a message 1372 to the application server 1316.
The application server 1316 does not encapsulate or decapsulate or extract the 200OK message and forwards it to the S-CSCF1318 of the remote UE, as shown by message 1374.
Thereafter, media 1380 is provided between the remote UE 1310 and the relay UE 1312. Further, the relay UE may then provide the media to the originating server as illustrated by arrow 1382.
As with the previous embodiments, the determined "line C" address may utilize at least one of the STUN or TURN described elsewhere in this disclosure. Further, in some cases, the line C address may be an IP address and port of the relay UE.
In the FIG. 13 embodiment, media capabilities may include, but are not limited to, a microphone, a speaker, a screen, a keyboard, and other options. Other speakers may feature multiple speakers, while the screen may feature screen resolution and supported frame rate.
Third mechanism to determine whether relay UE resources can be used
In another embodiment, the information flow may be between the remote UE and the relay UE. The mechanism assumes that registration has occurred for the relay UE, e.g., as described above with respect to fig. 9 or 10.
Reference is now made to fig. 14. In the embodiment of fig. 14, remote UE 1410 communicates with relay UE 1412. Further, the relay UE may communicate with the S-CSCF 1414 of the relay UE.
In the embodiment of fig. 14, the remote UE 1410 may send a query request, such as a SIP option, to the relay UE1412, as shown by message 1420.
The relay UE may provide an option response similar to the response of message 1322 above. The option response is sent back to the remote UE 1410 as message 1422. The options response may contain feature tags such as, for example, those provided in table 19 below.
Table 19: example feature tags for supported relay UE features
The remote UE 1410 may then subscribe to the capabilities of the relay UE using message 1424. Message 1424 may be similar to message 1324 from the embodiment of fig. 13 above.
The relay UE1412 can respond to the subscription message with a 200OK message, as shown by message 1426.
Once the resources become idle, as shown at block 1430, the relay UE1412 can notify the remote UE 1410 that the resources (e.g., microphone) are idle, as shown by a notification message 1432.
Subsequently, relay UE1412 receives the incoming SIP message as shown by message 1440. The relay UE may then forward the incoming SIP message to the remote UE 1410 using message 1442.
In this case, the remote UE 1410 knows that the relay UE has resources to process the SIP request and therefore may provide a back redirect in the form of a 3XX message 1450.
The relay UE1412 may then forward the 3XX message as shown by message 1452. Further, in some embodiments, instead of the 3XX message, an SDP response 1460 may be made to the incoming SIP request, in which case the SDP answer is forwarded as message 1462 to the originating server.
Likewise, media capabilities may include, but are not limited to, a microphone, a speaker, a screen, or a keyboard. The speakers may be further characterized by the number of speakers. The screen may be further characterized by a screen resolution and supported frame rate. The selected content may be determined to be one of a relay UE or a remote UE.
Further, the "C-line" address may be determined using at least one of STUN or TURN as described elsewhere in this disclosure, or may be determined based on the IP address and port of the relay UE 1412.
In another option, the remote UE 1410 may monitor these options to discover capabilities and provide redirection.
Fourth mechanism to determine whether relay UE resources can be used
According to another embodiment, another mechanism is provided to determine whether relay UE resources may be used. The mechanism assumes that a registration such as described in fig. 9 or 10 above has been performed.
In the present embodiment, the
The
Thus, as seen by
The SIP invite may then be received at the S-CSCF1514 of the remote UE. The invitation may be received, for example, using
The S-CSCF1514 of the remote UE forwards the SIP invite to the AS1518 AS
If the message does not contain the relay UE's capability status, a
Based on the capability status of the
Conversely, if the SIP request is to be provided to the relay UE, then AS1518 may send SIP request 1540 to the S-
The S-
The
In some cases, the messaging described above may utilize messages similar to those described in previous embodiments.
Fifth mechanism to determine whether relay UE resources may be used
According to another mechanism of determining whether relay UE resources may be used, the mechanism assumes that registration has occurred, e.g., using the embodiment of fig. 7 described above.
In the current embodiment, the relay UE is inserted into the path of all incoming and outgoing calls or sessions to and from the remote UE. This allows the relay UE to make decisions to route any incoming or outgoing calls or sessions to the remote UE, or to process, service or terminate the incoming or outgoing calls or sessions themselves. When processing media for a call or session, the relay UE may send the media to an output device associated with itself, or with another connected device such as an infotainment system. The output devices may include, for example, speakers, visual display units, and other options for output devices.
Referring now to fig. 16, a process for handling an incoming SIP request is shown. When an incoming call or session arrives at the IMS of the remote UE, the IMS 1616 of the remote UE forwards, proxies, or sends a SIP request for the incoming call or session to the IMS 1614 of the relay UE. Forwarding may be done according to standard SIP/IMS standards, such as the standards defined in the 3GPP TS 23.228 and 3GPP TS24.229 specifications. In the embodiment of fig. 16, the incoming SIP request is forwarded in message 1620. In some embodiments, the IMS 1614 of the relay UE and the IMS 1616 of the remote UE may be the same entity.
Upon receiving message 1620, IMS 1614 of the relaying-UE may add or include a relaying-UE indication to the received SIP request to inform the remote UE and/or relay U E that the SIP request is an SIP request that has been relayed. In other words, the SIP request does not originate from the relay UE's IMS 1614, and further, the call or session is intended to be relayed to the remote UE 1610.
The IMS 1616 of the remote UE or the IMS 1614 of the relay UE may be any of a P-CSCF, an I-CSCF, an S-CSCF, or an AS, among other options.
The relay UE indication may be a SIP header, a SIP header option, a SIP request body XML, and other options.
The relay UE's IMS 1614 may then forward the received SIP request for the incoming call or session to the relay UE1612 according to the SIP/IMS standards, e.g., standards defined in 3GPP TS 23.228 and 3GPP TS 24.229.
Upon receiving the message 1622, the relay UE1612 may detect that the SIP request is not intended for the relay UE. For example, the detection may be done based on a relay UE indication in the message, and/or by analyzing a request URI SIP header to determine that the SIP request is not addressed to the relay UE. The relay UE1612 then selects to service or terminate the incoming call/session itself, or forwards, proxies, or sends the call or session to a remote UE for service or termination, such as illustrated by message 1624 in the embodiment of fig. 16. As will be appreciated by those skilled in the art, if the relaying UE decides to serve the SIP request itself, message 1624 is omitted.
If the message 1624 is to be sent, the relay UE1612 may determine the remote UE1610 to route the call to by performing a lookup on the destination IMS/SIP identity. This may include the phone URI or SIP URI in a "request URI" SIP header or a "to" SIP header. The relay UE1612 may then obtain an address of the remote UE1610 or an interface identity of the relay UE1610 for which to route messaging to the remote UE by utilizing the binding. Such a binding may have been previously created, for example during a registration process.
If the remote UE1610 to which to forward the SIP request is determined, the relay UE1612 may create or construct a new SIP request using information from the received SIP request, and may perform one or more of the following: (a) the relay UE may exchange, replace, or swap some or all instances of its own IP address with the IP address of the remote UE; and/or (b) the relay UE may add or include a relay UE indication (such as SIP header, SIP header options, or SIP request body XML) to the SIP request to inform the remote UE: the SIP request is a SIP request that is being or has been relayed. In other words, the SIP request does not originate from the relay UE 1612.
The relay UE1612 may then send the new SIP request to the remote UE1610 in message 1624. The relay UE1612 may also create or construct a binding between the remote UE1610 and the sent SIP request to ensure that the received response to the SIP request can be relayed or proxied to the correct remote UE's IMS 1616.
Binding may include, but is not limited to, the following factors. If the same call ID is included in the SIP request sent to the remote UE1610, the relaying UE binds the call ID included in the SIP request received from the IMS 1616 of the remote UE to one or more identities of the remote UE1610 used on the local connection. Such identities may be the IP address of the remote UE used on the local connection, the MAC address belonging to the remote UE used for the local connection, the MAC address belonging to the relay UE used for the local connection, and other options.
The binding may further include information based on whether a different call ID is included in the SIP request sent to the remote UE 1610. In this case, the relay UE1612 may bind the call ID included in the SIP request received from the IMS 1616 of the remote UE to the call ID included in the SIP request sent to the IMS 1614 of the relay UE, and optionally also the identity of the remote UE1610 used on the local connection. For example, such an identity may be an IP address of the remote UE used on the local connection, a MAC address belonging to the remote UE for the local connection, a MAC address belonging to the relay UE used on the local connection, and other options.
If a remote UE is not found, the relay UE may send an error or SIP response to the IMS 1616 of the remote UE. Such a response may be, for example, a SIP 410 ("go (Gone)") response.
After receiving the message 1624, the remote UE1610 may provide a response according to standard procedures. For example, these standard procedures may include those defined in 3GPP TS 24.229. Thus, the remote UE1610 creates a SIP response, such as a SIP 200OK message, in message 1630 and sends it to the relay UE 1612. Message 1630 may be referred to as an "incoming SIP response".
After receiving the incoming SIP response message 1630 from the remote UE1610, the relay UE1612 performs a lookup of the call ID in the SIP response received from the relay UE's IMS in the binding store created above. If the lookup is successful such that the remote UE is found to be bound to the call ID in the SIP response received from the relay UE IMS, the relay UE1612 uses the information from the received SIP response to create or construct a new SIP response. The relay UE1612 may further perform one or more of an IP address exchange with the remote UE, replacement, or swapping out some or all instances of its own IP address.
Additionally or alternatively, the relay UE1612 may add or include a relay UE indication (such as SIP header, SIP header options, SIP request XML body, and other options) to a SIP register to inform the IMS 1614 of the remote UE: the response is already relayed and does not originate from the relay UE. The relay UE may then send a new SIP response to the relay UE's IMS 1614 in message 1632.
Additionally or alternatively, the relay UE may exchange, replace, or swap out some or all instances of the International Mobile Equipment Identifier (IMEI) of the remote UE with its own IMEI. The relay UE1612 may also include an indication of the IMEI of the remote UE. This may be done, for example, in the SIP header, in the XML body of the SIP register, and in other options.
After receiving the incoming SIP response 1632 from the relay UE1612, the nodes in the relay UE' S IMS (such as P-CSCFs, I-CSCFs, S-CSCFs, application servers, and other nodes) may then perform various functionalities. This may include adding or including an indication of a relay. Such a relay indication may be added by modifying the same fields or information elements (such as SIP header, SIP header options, SIP request body XML, and other options) as the relay UE indication in the SIP request. Alternatively, the indication may be accomplished by adding or including new field information elements (such as SIP headers, SIP header options, SIP request body XML, and other options) in the incoming SIP response 1634.
The indication may be forwarded in an incoming SIP response 1634 to a node in the IMS 1616 of the remote UE. The IMS for such remote UEs may include P-CSCF, I-CSCF, S-CSCF, AS, and other options. Forwarding may be accomplished using standard procedures such as those defined in the 3GPP TS24.229 specification.
After receiving the incoming SIP response 1634 from the relay UE's IMS 1614, the remote UE's IMS 1616 may then forward, proxy, or send the SIP response to the originator of the call or session. Thereafter, the call or session may then continue.
Based on the above, for an incoming call or session to the remote UE1610 registered via the relay UE1612, the relay UE1612 may select between different alternatives for routing and terminating or serving the incoming call or session. These may include the following five embodiments, which may be used alone or in combination with each other.
In a first embodiment, the relay UE1612 may show an on-screen message, for example using a display, or an audible alert or vibration, to prompt the user of the call or session as to whether to use the infotainment system or the remote UE1610 to process the media of the call or session.
In a second embodiment, the relay UE1612 may make the determination based on some configuration of the relay UE 1612. For example, if the remote UE1610 is set to prefer using an infotainment system, the relay UE1612 may choose to handle the call on its own. The configuration may be provided using settings on the device that are configurable through a user interface, a remote provisioning system such as a device management server, and other options.
In a third embodiment, the relay UE1612 may make the determination based on the availability of its own input or output resources, input or output resources of an associated infotainment system, and/or input or output resources of the destination or remote UE 1610. If the infotainment system is already terminating or servicing a call, the route of the incoming call or session may reach the destination remote UE 1610.
In a fourth embodiment, the relay UE1612 may make the determination based on a capability to handle the type of call or session, which may be based on the currently negotiated media for the call or session. The determination may be based on the capabilities of the relay UE1612, the associated infotainment system, and/or the destination remote UE 1610.
In the fifth embodiment, the relay UE1612 may make the determination based on the current state of the associated vehicle. For example, if the vehicle is traveling, it may be preferable to send an incoming video call to the heads-up display.
With respect to outgoing calls or sessions, reference is now made to fig. 17. The embodiment of fig. 17 provides an outgoing call or session to an endpoint outside of the IMS of the remote UE that has previously registered with the relay UE, such as through the embodiment of fig. 7 above.
The outgoing SIP request may include, but is not limited to, any of a SIP invite, a SIP update, a SIP message, or a SIP option. Alternatively, the outgoing SIP method in the SIP request may be any new SIP method.
In the embodiment of fig. 17, the remote UE1710 is the originator of the outgoing SIP request. Further, the relay UE1712 may be used to relay SIP messages. The IMS of the relay UE is shown in block 1714 and the IMS of the remote UE is shown in
An outgoing SIP request 1720 is sent from the remote UE1710 to the relay UE1712 via the local connection.
After receiving the SIP request at message 1720, the relay UE1712 may create or construct a new SIP request using information from the received SIP request, and may perform one or more of the following. The relay UE may exchange, replace, or swap out some or all instances of the IP address of the remote UE with its own IP address. The relay UE may further include a relay UE indication (such as SIP header, SIP header option, SIP request body XML, and other options) in the SIP request to inform the IMS of the remote UE: the SIP request is a SIP request being relayed. In other words, the SIP request does not originate from the relay UE. The relay UE may further or alternatively exchange, replace, or swap out some or all instances of the IMEI of the remote UE with its own IMEI, and may also include an indication of the IMEI of the remote UE. The further indication may be provided in a SIP header in the XML body of the SIP request, among other options.
The relay UE1712 may then send a new SIP request to the relay UE's IMS 1714 in message 1722. The IMS of the relay UE may be a P-CSCF, an I-CSCF, an S-CSCF, or an AS, among other options. It may further be any node, host entity, SIP server or SIP proxy in the network.
The relay UE1712 may also create a binding between the remote UE and the SIP request sent in message 1722 to ensure that the received response to the SIP request can be relayed or proxied to the correct
In other embodiments, the binding may be different if the call ID included in the SIP request sent to
After receiving the SIP request at message 1722, the node in IMS 1714 of the relay UE may perform an authentication or check: the relay UE1712 is permitted to perform the functions of the relay UE. The determination may be based on receiving the relay UE indication in the SIP request. If the check is performed and the relay UE is not allowed to perform the role of relay UE, an error or response may be sent back to the
Conversely, if the check is performed and the relay UE1712 is permitted to perform the role of the relay UE, or if the check is not performed, the same or another node in the relay UE's IMS 1714 may add the relay indication, which may be done by modifying the same fields or information elements (such as SIP header, SIP header options, SIP request body XML, and other options) as the relay UE indication in the SIP request, or by adding or including new fields or information elements (such as SIP header, SIP header options, SIP request body XML, and other options in the SIP request).
The IMS 1714 of the relay UE may then forward the received SIP request, including any modifications, to a node in the
Upon receiving message 1724, the
Conversely, if the check is performed and the remote UE is permitted to use the relay UE, or if the check is not performed, e.g., because the check was previously performed and stored during registration or at another time, the
In response to receiving the SIP response, the IMS 1714 of the relay UE may forward the received SIP response to the relay UE1712 in message 1732 using standard procedures defined in, for example, 3gpp ts 24.229.
Once the relay UE1712 receives the message 1732, it may perform a lookup in the binding repository for the call ID in the SIP response received from the relay UE's IMS. This lookup compares the call ID with the information stored after receiving message 1720. If the lookup is successful, the relay UE1712 may construct a new SIP response using information from the received SIP response and may perform various functionalities. This may include exchanging some or all instances of its own IP address with the IP address of the remote UE. It may further or may alternatively include adding a relay UE indication (such as SIP header, SIP header options, SIP request body XML, and other options) to the SIP request to inform the remote UE 1710: the SIP response is a relaying SIP response. In other words, the SIP response does not originate from the
The relay UE may then send a new SIP response to the remote UE1710 in message 1734.
After the above-described message transfer is completed, the call or session may then proceed.
At the relay UE1712, various procedures may be used to select whether to serve or forward the outgoing call or session. For an outgoing call or session, the node or element that originated the call or session may perform one of the following five tasks. These may be performed in conjunction with each other or separately from each other.
In a first embodiment, the relaying UE1712 may prompt the user of an incoming or outgoing call or session whether to use the infotainment system or the remote UE1710 to process media for the call or session. The prompts may be displays on a message screen, audible alerts, vibrations, and other options.
In a second embodiment, the relay UE1712 may make the determination based on certain configurations of the
In the third embodiment, the relay UE1712 may make the determination based on the availability of its own input or output resources and/or input or output resources including other elements of the infotainment system or the destination
In the fourth embodiment, the relay UE1712 may make the determination based on the capability to handle the type of call or session in progress. For example, the process may consider the capabilities of the relay UE1712, the associated infotainment system, the destination remote UE1710, and other elements in the system.
In the fifth embodiment, the relay UE1712 may make the determination based on the current state of the associated vehicle. For example, if the vehicle is traveling, different behaviors may occur.
The remote UE1710, the relay UE1712, and the infotainment system associated with the relay UE1712 may be restricted to only initiating certain types of calls or sessions. For example, the call or session may be limited to a call and/or session with a Public Service Access Point (PSAP), such as an emergency call, an electronic call, eSMS messaging, a location information reporting session, and other options. Such limits may be based on configuration.
For outgoing calls or sessions initiated from the relay UE1712 or the infotainment system on behalf of the remote UE1710, the relay UE1712 may route the calls or sessions to or from the IMS/SIP core and the network.
Media routing
The above embodiments may be accomplished using various techniques. In one embodiment, the port and IP address of the relay UE may be determined by sending a STUN bind request to the STUN server address. The IP address or port number may then be used as a candidate in SDP offers and replies to send media when routing the media to the remote UE.
In other embodiments, a TURN server may be utilized such that the port and IP address of the TURN server may be determined by sending a TURN assignment message. In this case, the port and IP address of the TURN server may be used in SDP offers and replies to route media to remote UEs.
Referring now to fig. 18, a mobile-originated SIP request is shown. The technique of fig. 18 may also be used with SDP answers containing a "C-line".
Thus, according to fig. 18, once the remote UE 1810 has a connection with the relay UE1812, such as described in other embodiments of the disclosure, the remote UE 1810 may send a STUN binding request to the relay UE 1812. The STUN bind request is shown as message 1820. In message 1820, the STUN server address may be provided statically or dynamically.
Once the relay UE1812 receives the message 1820, if the remote UE 1810 is permitted to use the relay UE1812 and permitted to use STUN, the relay UE1812 sends a message 1822 to the application server 1814, the message 1822 including the message 1820 and the source IP address of the relay UE 1812. In this case, the application server 1814 includes a STUN server 1816, and may include a TURN server 1817.
The application server 1814 sends a STUN bind response 1824, which STUN bind response 1824 contains the source IP address received in the STUN bind request 1822 as a STUN payload address.
The relay UE1812 receives the message 1824 and sends the message as a message 1826 to the remote UE 1810. The remote UE then receives message 1826.
After receiving the message 1826, the remote UE knows the SDP "C-line" for future SDP offers and answers. In other words, the STUN payload address is known to the remote UE.
Although the STUN server is shown above AS being part of the AS 1814, in other embodiments, the STUN server may be part of the relaying-UE 1812.
As described in other embodiments above, once the remote UE has a connection with the relay UE1812, the remote UE 1810 may send a TURN assignment message 1830 to the relay UE 1812. The TURN server address may be provided statically or dynamically. The providing may be done, for example, using the embodiments described above.
Then, the relay UE1812 receives the TURN assignment message 1830.
Upon receipt of the message 1830, if the remote UE is allowed to use the relay UE and is allowed to use TURN, the relay UE1812 forwards the message 1830 to the AS 1814, AS shown by message 1832 in the embodiment of fig. 18.
The AS 1814 sends an assignment response message 1834 through the TURN server 1817, the assignment response message 1834 containing the IP address and port of the TURN application server. This is sent to the relay UE1812, which may then send a message to the remote UE 1810 as shown by message 1836.
Thereafter, the TURN session is configured and a keep alive message, shown as message 1840, may be provided until the SIP session is required to be unknown.
The remote UE 1810 then provides the SIP invite message 1850. The SIP invite contains an SDP offer with a C-line equal to the TURN server address and port, as received in message 1836. The SIP invite is sent to the relay UE1812 in message 1850 and then forwarded to the SIP UA 1818 in message 1852.
Then, as shown in message 1860, RTP packets may be returned to TURN server 1817, and message 1862 may be sent from the TURN server to relay UE 1812.
From relay 1812, the TURN data indication plus RTP packet may be sent to remote UE 1810 in message 1864.
Those skilled in the art will appreciate that the above methods and embodiments can be mixed to create additional methods.
Further, in the case of a reference indication or indicator, it may be any of the following provided in table 20 below.
Table 20: possible ways of communicating an indication/indicator
The indicator may be a boolean value in nature or take on a variable value.
Further, the encoding used in the various embodiments above may use, but is not limited to, the implementation of table 21 below.
Table 21: example code implementation
Further, some embodiments above indicate that the first SIP request or response is encapsulated in the second SIP request or response. This solution generally describes the second SIP request as a SIP message method. However, it could equally be a SIP information or a SIP update. The SIP method includes an origination message and its response.
In the above embodiments, the feature tag name, the codepoint value, and the name thereof are used for illustrative purposes only, and are not absolute.
The construct "+ g.3gpp.something" is used in the above table. This construct is typically used in feature tags that may be included in the SIP field and allows for carrying such syntax information, such as contact header, accept contact header, feature cap header, or using any of the mechanisms in table 20 above.
The modules and user devices and devices described above may be any computing device or network node. Such computing devices or network nodes may include any type of electronic device, including but not limited to mobile devices such as smartphones or cellular phones. Examples may further include fixed or mobile user devices, such as internet of things (IoT) devices, endpoints, home automation devices, medical devices in a hospital or home environment, inventory tracking devices, environmental monitoring devices, energy management devices, infrastructure management devices, vehicles or devices for vehicles, fixed electronic devices, and so forth. Vehicles include automotive vehicles (e.g., automobiles, cars, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aircraft systems, drones, helicopters, etc.), spacecraft (e.g., space shuttle, space capsule, space station, satellite, etc.), watercraft (e.g., ships, boats, hovercraft, submarines, etc.), rail vehicles (e.g., trains, trams, etc.), and other types of vehicles, including any combination of any of the above, whether currently existing or later developed.
A simplified diagram of a computing device is shown with respect to fig. 19. The computing device of FIG. 19 may be any UE, S-CSCF, P-CSCF, I-CSCF, TURN server, STUN server, AS, or other node AS described above.
In fig. 19, a
The
Alternatively, or in addition to
The
In one embodiment, communication between the various elements of the
Further, if the computing station is a user device, an example user device is described below with respect to fig. 20.
In the case of enabling two-way communication by the
Network access requirements will also vary depending on the type of
When required network registration or activation procedures have been completed, the
Signals received by the
The
Some of the subsystems shown in fig. 20 perform communication-related functions, whereas other subsystems may provide "resident" or on-device functions. Notably, some subsystems, such as the
Operating system software used by the
As shown,
The applications and software may be stored on any computer-readable storage medium. The computer-readable storage medium may be a tangible or transitory/non-transitory medium such as optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), or other memory known in the art.
One software application may be a Personal Information Manager (PIM) application having the ability to organize and manage data items relating to the user of the user device such as, but not limited to, e-mail, messages, calendar events, voice mails, appointments, and task items. Other applications, including productivity applications, social media applications, games, etc., may also be loaded onto the
In a data communication mode, a received signal, such as a text message or web page download, will be processed by the
The user of the
In the case of voice communications, the overall operation of the
The embodiments described herein are examples of structures, systems or methods having elements corresponding to the elements of the technology of the present application. This written description may enable those skilled in the art to make and use embodiments having alternative elements that likewise correspond to the elements of the techniques of this application. Accordingly, the intended scope of the present technology includes other structures, systems or methods that do not differ from the technology described herein, and further includes other structures, systems or methods that do not differ substantially from the technology described herein.
Although operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be used. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
Moreover, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made.
While the above detailed description has shown, described, and pointed out fundamental novel features of the disclosure as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the system illustrated may be made by those skilled in the art. Additionally, the order in which the method steps appear in the claims does not imply their order.
This may not be immediate or directly from the server when the message is sent to or from the electronic device. They may be delivered synchronously or asynchronously from a server or other computing system infrastructure supporting the apparatus/methods/systems described herein. The foregoing steps may include, in whole or in part, synchronous/asynchronous communications to/from devices/infrastructure. Also, the communication from the electronic device may be to one or more endpoints on a network. These endpoints may be served by servers, distributed computing systems, stream processors, and the like. A Content Delivery Network (CDN) may also provide for providing communications to the electronic devices. For example, in addition to typical server responses, the server may provide or indicate data for use by a Content Delivery Network (CDN) to wait for the electronic device to download at a later time, such as subsequent activity by the electronic device. Thus, the data may be sent directly from a server or other infrastructure (such as a distributed infrastructure or CDN) as part of the system or separate from the system.
In general, a storage medium may include any or some combination of the following: semiconductor memory devices such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks such as fixed, floppy, and removable disks; another magnetic medium, including magnetic tape; optical media such as Compact Discs (CDs) or Digital Video Discs (DVDs); or another type of storage device. It is noted that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed in a large system, possibly with multiple nodes. Such computer-readable or machine-readable storage media are considered to be part of an article (or article of manufacture). An article or article of manufacture may refer to any manufactured component or components. The one or more storage media may be located in a machine that executes the machine-readable instructions, or at a remote site where the machine-readable instructions are downloaded over a network for execution.
In the previous description, numerous details were set forth to provide an understanding of the subject matter disclosed herein. However, embodiments may be practiced without some of these details. Other embodiments may include modifications and variations to the details discussed above. It is intended that the appended claims cover such modifications and variations.