WO2017034511A1

WO2017034511A1 - Bearer binding in the presence of a ue-to-network relay

Info

Publication number: WO2017034511A1
Application number: PCT/US2015/000465
Authority: WO
Inventors: Alexandre Stojanovski
Original assignee: Intel IP Corporation
Priority date: 2015-08-24
Filing date: 2015-12-26
Publication date: 2017-03-02
Also published as: TWI726893B; TW201709767A

Abstract

A user equipment device (UE) may operate as a relay device (referred to as a relay UE) between other UEs (referred to as remote UEs) and a wireless telecommunications network. The wireless telecommunications network may allocate a bearer to the relay UE, and the remote UEs may initiate calls via an Internet Protocol (I P) multimedia subsystem (I MS) of a wireless telecommunications network. A Proxy Call Session Control Function (P- CSCF), a Packet Data Network (PDN) Gateway (PGW), and a Policy and Charging Rules Function (PCRF) may collaborate to bind the calls of the remote UEs to the bearer allocated to the relay UE in order to, for example, increase the number of UEs that may participate in calls via the relay UE.

Description

BEARER BINDING IN THE PRESENCE

OF A UE-TO-NETWOR RELAY

RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional Patent Application No. 62/209,092, which was filed on August 24, 2015, the contents of which are hereby incorporated by reference as though fully set forth herein.

BACKGROUND

Wireless networks may provide network connectivity to mobile communication devices, such as smart phones. The network connectivity may be provided through radio interfaces. Typically, the devices may connect to a network through an access point that is part of the network infrastructure. For example, a device may connect to a cellular network via a cellular base station or a wireless local area network (WLAN) via a WLAN access point (e.g., a WiFi access point).

Some techniques may allow devices to establish direct communication paths with one another (e.g., without going through a cellular base station or WiFi access point). For example, devices that are located in proximity to one another may discover one another and subsequently establish direct communication paths with one another. Examples of direct communication technologies include the WiFi Direct® standard or direct communications as discussed in the technical report "3GPP TR 22.703, Technical Specification Group Services and Systems Aspects; Study on architecture enhancements to support Proximity Services (ProSe) (Release 12)" (available at www.3gpp.org).

In some scenarios, mobile communication devices may operate as relay devices between other mobile communication devices and a wireless network. For instance, a first mobile communication device may establish a direct connection with a wireless network and another connection with a second mobile communication device that, for example, is located outside of the coverage area of the wireless network. The first mobile communication device may enter into a relay mode that enables the second mobile communication device to communicate with the wireless telecommunications network by relaying information between the second mobile communication device and the wireless network. BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments described herein will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals may designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.

Fig. 1 is a diagram i llustrating an example system in which systems and/or methods described herein may be implemented;

Fig. 2 is a diagram of example devices and interfaces that may be used to establish a call for a remote user equipment device (UE);

Fig. 3 is a diagram illustrating an example process for establ ishing a call for a remote UE;

Fig. 4 is a sequence flow diagram illustrating an example process for establishing a call for a remote UE;

Fig. 5 illustrates, for one embodiment, example components of an electronic device; and Fig. 6 is a diagram of example components of a device.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents.

A user equipment device (UE) may operate as a relay device (referred to herein as a relay UE or UE-to-Network Relay) between one or more UEs (referred to herein as remote UEs) and a wireless telecommunications network. However, currently available relay technologies may include certain limitations. For instance, a UE may only operate as a relay device to a limited number of UEs.

For example, remote UEs may connect to a relay UE and participate in cal ls via an Internet Protocol (IP) multimedia subsystem (IMS) of a wireless telecommunications network. Each time a remote UE participates in such a call, the wireless

telecommunications network may create a new bearer for the call. However, since the relay UE may only be capable of supporting a limited number of bearers at any one time (e.g., 8 or 1 1 depending on the 3rd Generation Partnership Project (3GPP) specification being implemented), the number of remote UEs that can participate in calls via the relay UE may be limited. As such, the manner in which the wireless telecommunications network establishes calls from remote UEs may limit the number of remote UEs that the relay UE may support.

Techniques described herein may enable a relay UE to support a greater number of remote UEs by causing calls initiated by remote UEs to be bound to existing bearers. For example, a relay UE may establ ish a packet data network (PDN) connection with a wireless telecommunications network, which may include a bearer being allocated to the relay UE. A remote UE may connect to the relay UE and may register, as a remote UE, with an IMS of the wireless telecommunications network.

The remote UE may initiate a call via the IMS, which may include providing the IMS with a call quality (e.g., a Quality of Service (QoS)) for the call. The IMS may inform a core network of the wireless telecommunications network of the call and the call quality associated with the call. The core network may determine whether any bearers (with the call quality) have already been created for the relay UE. If such a bearer does not currently exist, the core network may create a new bearer to accommodate the call. By contrast, if such a bearer has been created, the core network may bind the call to the existing bearer and may modify the existing bearer to accommodate the call (and call quality) being added to the bearer. As such, by combining the calls from remote UEs onto the same bearer, the technologies described herein may increase the number of remote UE calls that can be supported by a relay UE.

Fig. 1 is a diagram of an example environment 100 in which systems and/or methods described herein may be implemented. Environment 100 may include user equipment (UEs) 1 10, one or more radio access networks (RANs), a wireless telecommunications network, and one or more external networks. The wireless telecommunications network may include an Evolved Packet System (EPS) that includes a Longer Term Evolution (LTE) network and/or an evolved packet core (EPC) network that operates based on a 3GPP wireless communication standard. The LTE network may be, or may include, RANs that include one or more base stations, some or all of which may take the form of enhanced Node Bs (eNBs) 1 1 5, via which UEs 1 10 may communicate with the EPC network.

The EPC network may include Serving Gateway (SGW) 120, Packet Data Network (PDN) Gateway (PGW) 125, Mobility Management Entity (MME) 130, Home Subscriber Server (HSS) 135, and/or Policy and Charging Rules Function (PCRF) 140. As shown, the EPC network may enable UEs 1 10 to communicate with an external network, such as a Public Land Mobile Networks (PLMN), a Public Switched Telephone Network (PSTN), and/or an IP network (e.g., the Internet).

The wireless telecommunications network may also include an IMS core, which may include Telephony Application Server (TAS) 150 and Proxy Call Session Control Function (P- CSCF) 155. In some implementations, the IMS core may include additional devices, such as other Call Session Control Function (CSCF) devices, media servers, application servers, etc. The IMS core may help deliver IP multimedia services, such as Voice over IP (VoIP) services, video calling services, etc., to UEs 1 10. Additionally, the IMS core may operate based on the 3GPP wireless communication standard.

UE 1 10 may include a portable computing and communication devices, such as a personal digital assistant (PDA), a smart phone, a cellular phone, a laptop computer with connectivity to the wireless telecommunications network, a tablet computer, etc. UE 1 10 may also include a non-portable computing device, such as a desktop computer, a consumer or business appliance, a smart television, or another device that has the ability to connect to the wireless telecommunications network. UE 1 10 may also include a computing and

communication device that may be worn by a user (also referred to as wearable devices) as a watch, a fitness band, a necklace, glasses, an eyeglass, a ring, a belt, a headset, or another type of wearable device. UE 1 10 may capable of performing one or more of the operations described herein, such as establishing a device-to-device (D2D) connection with another UE 1 10 and operating as a relay UE or as a remote UE. Additionally, UE 1 10 may be capable of participating in calls (e.g., an IMS call) supported by the wireless telecommunications network, which may include using an appropriate protocol, such as Session Initiation Protocol (SIP). eNB 1 1 5 may include one or more network devices that receive, process, and/or transmit traffic destined for, and/or received from, UE 1 10. eNB 1 15 may receive traffic from, and/or send traffic to, external networks or other devices via SGW 120 and PGW 125. eNB 1 15 may send traffic to, and/or receive traffic from, UEs 1 10 via an air interface.

SGW 120 may aggregate traffic received from one or more eNBs 1 15 and may send the aggregated traffic to another network or device via PGW 125. Additionally, SGW 120 may aggregate traffic received from one or more PGWs 125 and may send the aggregated traffic to one or more eNBs 1 15. SGW 120 may operate as an anchor for the user plane during inter-eNB handovers and as an anchor for mobility between different telecommunication networks. PGW 125 may include one or more network devices that may aggregate traffic received from one or more SGWs 120, and may send the aggregated traffic to an external network or another device. PGW 125 may also, or alternatively, receive traffic from an external network and may send the traffic toward UE 1 10 (via SGW 120 and/or eNB 1 15).

MME 130 may include one or more computation and communication devices that act as a control node for eNB 1 15 and/or other devices that provide the air interface for the wireless telecommunications network. For example, MME 130 may perform operations to register UE 1 10 with the wireless telecommunications network, to establish bearer channels (e.g., traffic flows) associated with a session with UE 1 10, to hand off UE 1 10 to a different eNB, MME, or another network, and/or to perform other operations. MME 120 may perform policing operations on traffic destined for and/or received from UE 1 10.

HSS 135 may include one or more devices that may manage, update, and/or store, in a memory associated with HSS 135, profile information associated with a subscriber (e.g., a subscriber associated with UE 1 10). The profile information may identify applications and/or services that are permitted for and/or accessible by the subscriber; a Mobile Directory Number (MDN) associated with the subscriber; bandwidth or data rate thresholds associated with the applications and/or services; and/or other information. The subscriber may be associated with UE 1 10. Additionally, or alternatively, HSS 135 may perform authentication, authorization, and/or accounting operations associated with the subscriber and/or a communication session with UE 1 10.

PCRF 140 may include one or more devices that may receive information regarding policies and/or subscriptions from one or more sources, such as subscriber databases and/or from one or more users. PCRF 140 may provide these policies to PGW 125 or another device so that the policies can be enforced. As depicted, in some implementations, PCRF 140 may communicate with PGW 125 to ensure that charging policies are properly applied to locally routed sessions within the telecommunications network. For instance, after a locally routed session is terminated, PGW 125 may collect charging information regarding the session and provide the charging information to PCRF 140 for enforcement.

PCRF 140 may also be capable of performing additional operations described herein. For example, PCRF 140 may communicate with PGW 125 to establish a Gx session (e.g., a session involving the Gx interface of the 3GPP wireless communication standard) for relay UE 1 10. In another example PCRF 140 may communicate with P-PSCF 155 to establish a Rx session (e.g., a session involving the Rx interface of the 3GPP wireless communication standard) for remote UE 1 10. In yet another example, PCRF 140 may identify (or cause PGW 125 to identify) an existing bearer (e.g., an EPS bearer) that is associated with relay UE 1 10 and that is suitable (e.g., a bearer already associated with a QoS for the call) for handling a call from a remote UE 1 10. Additionally, PCRF 140 may modify (or cause PGW 125 to modify) the capacity of the existing bearer to handle the new call. In scenarios where there are no bearers that are suitable for handling the new call, PCRF 140 may cause a new bearer to be created for the call; however, PCRF 140 may be configured to prioritize mapping new calls to existing bearers (instead of creating new bearers) in order to increase the number of remote UEs 1 10 that might be served by relay UEs 1 10.

TAS 150 may include one or more computation and communication devices that may provide IP call (e.g., VoIP) services. TAS 150 may translate a telephone number into an IP address and/or an IP address into a telephone number in order to establish a call. TAS 150 may also provide call routing and/or call bridge services. TAS 150 may also provide answering services, call forwarding services, and free-call routing services (e.g., for so-called " 1 -800" numbers). TAS 150 may operate based on a particular communication protocol, such as SIP.

P-CSCF 155 may include one or more computation and communication devices that may gather, process, search, store, and/or provide information in a manner described herein. P-CSCF 155 may operate as a first point of contact for the IMS core. For instance, SIP messages, from UEs 1 10, to the IMS core may first be intercepted by P-CSCF 155. In some implementations, communications between UEs 1 10 and P-CSCF 155 may involve a particular interface, such as the Gm interface (not shown) of the 3GPP wireless communications standard.

The quantity and arrangement of devices and/or networks, illustrated in Figs. I is provided for explanatory purposes only. In practice, there may be additional devices and/or networks; fewer devices and/or networks; different devices and/or networks; or differently arranged devices and/or networks than illustrated in Fig. 1 . Alternatively, or additionally, one or more of the devices illustrated in Fig. 1 may perform one or more functions described as being performed by another one or more of the devices illustrated in Fig. 1. The illustrated devices may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

Fig. 2 is a diagram of example devices and interfaces that may be used to establish a call for remote UE 1 1 0. As shown, the example devices may include remote and relay U Es 1 10, PGW 125, PCRF 140, and P-CSCF 1 55, examples of which are described above with reference to Fig. 1 . The example interfaces include a Gx interface, a Gm interface, and an Rx interface.

Relay UE 1 1 0 may establish a PDN connection that involves PGW 1 25. In doing so, relay UE 1 10 may be assigned an I P version 6 (I Pv6) address with a shortened prefix, such as a /56 prefix. While the PDN connection is being established, PGW 125 may establish a communication session with PCRF 140 via the Gx interface, which may include PGW 125 communicating the IPv6 prefix of relay UE 1 10 to PCRF 140. The

communication session may be referred to as a Gx session. Establishing the PDN connection may cause a bearer (e.g., an EPS bearer) to be assigned to relay UE 1 10.

Remote UE 1 10 may discover and establish a D2D connection with relay UE 1 1 0. In some embodiments, the connection may be an LTE direct connection, a proximity services (ProSe) connection, etc. Additionally, relay UE 1 1 0 may assign an I Pv6 address to remote UE 1 10. In some embodiments, relay UE 1 1 0 may use I Pv6 prefix delegation to assign an IPv6 address with a longer prefix, such as /64 prefix, to remote UE 1 1 0.

Additionally, other remote UEs 1 10 that connect to relay UE 1 10 may be assigned IPv6 addresses (and prefixes) in a similar manner, such that the longer IPv6 prefixes of al l the remote UEs 1 10 may be logically aggregated into the shorter IPv6 prefix of relay UE 1 10, which as is explained in greater detail below, may be significant for PCRF 140 to map cal ls initiated by remote UEs 1 10 with bearers assigned to relay UE 1 10.

Remote UE 1 10 may register for IMS services by communicating with P-CSCF 1 55 via the Gm interface. While registering, remote UE 1 10 may indicate to P-CSCF 1 55 that remote UE 1 10 is operating as a remote device (e.g., communicating via relay UE 1 10). P- CSCF 1 55 may then establish a communication session with PCRF 140 via the Rx interface. The communication session may be referred to as an Rx session. In some embodiments, P-CSCF 1 55 may indicate, to PCRF 140, that the Rx session corresponds to remote UE 1 10 (e.g., a UE 1 10 operating as a remote UE 1 10). Establishing the Rx session may include P-CSCF 1 1 5 communicating the I Pv6 prefix of remote UE 1 10 to PCRF 140, which may enable PCRF 140 to perform session binding by mapping the Rx session of remote UE 1 10 and the Gx session of relay UE 1 10. For example, since the IPv6 prefix of remote UE 1 10 may be based on the IPv6 prefix of relay UE 1 1 0 (via I Pv6 prefix delegation), PCRF 140 may use the I Pv6 prefix of remote U E 1 10 to identify the I Pv6 address of relay UE 1 10. Additionally, since the IPv6 prefix of remote U E 1 1 0 may be sent to PCRF 140 while establishing the Rx session, and the I Pv6 address of relay UE 1 1 0 may be sent to PCRF 140 while establishing the Gx session, PCRF 140 may map the Rx session of remote UE 1 1 0 to the Gx session of relay UE 1 1 0.

After establishing an IMS session, remote UE 1 10 may send a request to P-CSCF

1 55 to establish a call (e.g., an I MS call) with another UE. The request may include an indication that the request is from remote UE 1 1 0 and/or information describing a level of quality for the call (also referred to herein as call quality information). Examples of such information may include QoS information and Allocation and Retention Priority (ARP) information. PCRF 140 may update the Rx session based on the call quality information and may include P-CSCF 155 indicate to PCRF 140 that the call request is from remote UE 1 1 0.

PCRF 140 may then instruct PGW 1 25 to perform bearer binding by binding the I P flow corresponding to the call with a bearer that may: 1 ) be assigned to relay UE 1 10; and 2) include one or more other I P flows that may include the level of quality for the newly requested call. If such a bearer exists, PGW 1 25 may modify the bearer to accommodate the newly added IP flow while stilling accommodating the level of quality for the calls already associated with the bearer. If such a bearer does not exist, PGW 125 may create a new bearer for the I P flow corresponding to the call.

Fig. 3 is a diagram illustrating an example process 300 for establishing a call (or another type of communication session) for remote UE 1 10. Process 300 may be implemented by one or more network devices, such as PGW 125, PCRF 140, and P-CSCF 1 55.

Process 300 may include establishing a Gx session for relay UE 1 10 (block 3 1 0).

For example, relay UE 1 10 may establish a PDN connection with a wireless

telecommunications network, which may include a Gx session begin established between PGW 125 and PCRF 140. Establishing the Gx session may include assigning a bearer (e.g., an EPS bearer) that relay UE 1 10 may use to communicate with the wireless telecommunications network. In some embodiments, the Gx session may include an IP connectivity access network (I P-CAN) session, and the bearer may include an I P-CAN bearer. In some embodiments, establishing the Gx session may include the I Pv6 of relay UE 1 1 0 being communicated from PGW 1 25 to PCRF 140.

Process 300 may also include registering remote UE 1 10 for IMS services (block 320). For instance, P-CSCF 1 55 may receive a request, from remote UE 1 1 0, to register with an IMS of the wireless telecommunications network. The request to register remote UE 1 10 for I MS services may include an indication (e.g., one or more parameters) indicating that the request originated from remote UE 1 10. In some implementations, the request may include an SI P REGI STER message and may include an I Pv6 prefix of remote UE 1 1 0.

Process 300 may also include establishing an Rx session for remote UE 1 1 0 (block 330). For example, P-CSCF 1 55 may establish a communication session with PCRF 140. Establishing the Rx session may include P-CSCF 1 55 communicating a session request message (e.g., an [Rx] Authentication-Authorization Request (AA-REQUEST) message) to PCRF 140. In some embodiments, the request message may include an indication (e.g., one or more parameters) indicating that the request originated from remote UE 1 10 (as opposed to a UE operating in another mode of operation or scenario).

Process 300 may also include performing session binding between the Gx session of relay UE 1 10 and the Rx session of remote UE 1 1 0 (block 340). For instance, when the Gx session is established for relay UE 1 10, PCRF 1 10 may receive the I Pv6 address (which include an IPv6 prefix) of relay UE 1 10. Similarly, when the Rx session is established for remote UE 1 10, PCRF 140 may receive the IPv6 prefix of remote UE 1 10. Additionally, since the IPv6 prefix of remote UE 1 10 may have been assigned to remote UE 1 10 based on the I Pv6 prefix of relay UE 1 1 0, PCRF 140 may determine the Gx session that corresponds to the Rx session based on the I Pv6 prefix of U E 1 10. Once the Rx session and corresponding Gx session are identified, PCRF 140 may perform session binding by logically mapping the Rx session to the Gx session.

Process 300 may also include receiving a request to establish a call between remote UE 1 10 and another UE 1 1 0 (block 350). For example, P-CSCF 140 may receive a request from remote UE 1 10 to establish a call (e.g., a VoI P call) with another UE 1 1 0. In some implementations, the request to establish the call may include a SI P INVITE message. Additionally, the request may indicate that the request originated from remote UE 1 1 0 (as opposed to, for example, a UE device operating as a relay device or operating in a standard mode of operation).

Process 300 may also include updating the Rx session of remote UE 1 1 0 (block 360). For instance, in response to receiving a request from remote U E 1 10 to establish a call with another UE 1 10, P-CSCF 140 may update the Rx session that was established when remote UE 1 10 was registered from IMS services. In some embodiments, updating the Rx session may include identifying information (e.g., in the request to establish the call) that describes the level of quality that should accompany the call. Examples of such information may include QoS parameters, ARP parameters, guaranteed bit rate (GBR) parameters, and/or another type of information describing the level of quality that should accompany the call. In some embodiments, the QoS parameters may include QoS class identifier (QCI). Updating the Rx session may also include communicating the quality information and/or information identifying remote UE 1 10 to PCRF 140. In some embodiments, P-CSCF 1 55 may communicate the information to PCRF 140 using AA- REQUEST message to PCRF 140. Process 300 may also include performing bearer binding for the call (block 370). For example, PCRF 140 may create a policy and charging control (PCC) rule and/or a QoS rule (also referred to as a PCC/QoS rule) and communicate the PCC/QoS rule to PGW 1 25. In some embodiments, the PCC/QoS rule may instruct PGW 1 25 to associate the new I P flow, corresponding to the call initiated by remote UE 1 1 0, with a bearer that has one or more other I P flows of the same quality (e.g., QCI, ARP, etc.) as the new I P flow.

Additionally, the PCC/QoS rule may instruct PGW 125 to create a new bearer for the new I P flow. In some embodiments, PCRF 140 may communicate the PCC/QoS rule to PGW 1 25 using a CC-REQUEST message, which may also include quality information (e.g., QCI, ARP, etc.) for the call and/or an indication that the call corresponds to remote UE 1 1 0. In some embodiments, the quality information and the indication that the call corresponds to remote UE 1 1 0 may be part of the PCC/QoS rule.

As such, PGW 125 may determine whether an existing bearer (e.g., an EPS bearer associated with relay UE 1 1 0) includes I P flows that correspond to the same quality (e.g., QCI, ARP, etc.) as the new IP flow corresponding to the call initiated by remote UE 1 1 0. If such a bearer does not currently exist, PGW 125 may create a new bearer (associated with relay UE 1 10) and may assign the new IP flow to the new bearer. However, if such a bearer does exist, PGW 125 may aggregate the new IP flow to the existing bearer (or to the I P flows of the existing bearer). In some embodiments, when the new I P flow is aggregated to an existing bearer, PGW 125 may modify the bearer (e.g., the network resources associated with the bearer) to ensure that the bearer may accommodate the quality for all the I P flows associated with the bearer.

Fig. 4 is a sequence flow diagram il lustrating an example process for establishing a call for remote UE 1 1 0. As shown, the example of Fig. 4 may include remote UE 1 10, relay UE 1 10, MME 1 30, SGW/PG W 1 20/125, PCRF 140, and P-CSCF 1 55. The example devices shown in Fig. 4 are described above with reference to Fig. 1 .

As depicted, relay UE 1 1 0 may establish a PDN connection with a wireless telecommunications network, which may involve several network devices, such as MME 1 30, SGW/PG W 120/1 25, and/or PCRF 140 (block 4.1 ). While establishing the PDN ^' connection, relay UE 1 10 may be assigned an I Pv6 address that may include a shortened IPv6 prefix, such as an /56 prefix. Additionally, the PDN connection may include an I P- CAN session (also referred to herein as a Gx session) between PGW 1 25 and PCRF 140, which may include PGW 1 25 communicating the IPv6 address of relay UE 1 1 0 to PCRF 140. Remote UE 1 10 may discover and connect to relay UE 1 10 (block 4.2). The connection between remote and relay UEs 1 1 0 may include a ProSe connection, a peer-to- peer (P2P) connection, a D2D connection, an LTE direct connection, etc. Whi le establishing the connection, relay UE 1 10 may assign an I Pv6 address to remote UE 1 10. The IPv6 address assigned to remote UE 1 10 may include an I Pv6 prefix based on the IPv6 prefix of the IPv6 address assigned to relay UE 1 10. For instance, relay UE 1 1 0 may use I Pv6 prefix delegation to assign an I Pv6 prefix, to remote UE 1 1 0, which is a longer version (e.g., a /64 prefix) than the IPv6 prefix of relay UE 1 10. As described above, doing so may enable PCRF 140 to map Rx sessions of remote UE 1 10 to Gx session of relay 1 10.

At some point, remote UE 1 10 may communicate a request to register with an IMS of the wireless telecommunications network. As shown, P-SCSF 1 55 may receive the request. Additionally, the request may include a SI P REGISTER message that includes parameters (also referred to herein as relay information or relay parameters) indicating that the request is from a UE operating as a remote UE (line 4.3).

In response to the registration request, P-CSCF 1 55 may communicate with PCRF 140 to establish an Rx session for remote UE 1 10 (block 4.4). In some embodiments, establishing the Rx session may include P-CSCF 1 55 sending an AA-REQUEST message, via the Rx interface, to PCRF 140. As shown, establishing the Rx session may include P- CSCF 1 55 sharing the relay parameters with PCRF 140.

At some point after remote UE 1 10 is registered for IMS services and the Rx session has been established, remote UE 1 1 0 may communicate a request to initiate a call with another UE. In some implementations, the request may include a SIP INVITE message. Additionally, the request to initiate the call may include information indicating a level of quality for the call. As described above, examples of such information may include a QCI, ARP information, etc.

Depending on the embodiment, the request to register from I MS services and/or the request to initiate the call may include an indication that the request originated from a UE operating as a remote UE. For instance, in some embodiments only the request to register for IMS services or the request to initiate the call may include an indication that the requests originated from a UE operating as a remote UE. However, as shown, in some embodiments remote UE 1 10 may include the indication (e.g., relayed parameters) in both of the requests (i .e., the request to register for IMS services or the request to initiate the call). In response to the request to initiate the call, P-CSCF 1 55 and PCRF 140 may update the Rx session with the relayed parameters (block 4.6). For example, P-CSCF 1 55 may send an AA-REQUEST message to PCRF 140 using the Rx interface. The AA- REQUEST may include the quality information (e.g., the QCI, ARP information, etc.) and/or the relay parameters included in the SIP INVITE message from remote UE 1 1 0. As such, PCRF 140 may become aware that: 1 ) the call request originated from remote UE 1 10; and 2) the corresponding call includes a certain level of quality.

As shown, PCRF 140 and PGW 125 may update the Gx session (block 4.7). For example, PCRF 140 may generate and communicate instructions (also referred to herein as a PCC/QoS rule) about how PGW 125 should manage the new IP flow corresponding to the call requested by remote UE 1 1 0. In some embodiments, PCRF 140 may communicate the instructions to PGW 125 using a CC-REQUEST message via the Gx interface. The instructions may include mapping the new I P flow of the call to a bearer that is capable of accommodating the level of quality for the requested call. The instructions may also include a preference for aggregating the new I P flow of the call to IP flows, of an existing bearer, which may have the same level of quality as the new I P flow and/or modifying the existing bearer (e.g., the network resources of the existing bearer) to accommodate the level of quality of the new IP flow. For example, if the new I P flow includes a GBR, the resources of the existing bearer may be enhanced by an amount and in a manner commensurate with accommodating the GBR of the new IP flow. In some embodiments, the instruction may include creating a new bearer for the new I P flow if a bearer, associated with IP flows of the same level of quality as the new I P flow, does not already exist.

For the purposes of explaining the example of Fig. 4, assume that there is an existing bearer associated with I P flows of the same level of quality as the new I P flow. As such, the new I P flow may be al located to the existing bearer. Additionally, the existing bearer may be modified to ensure that the existing bearer may accommodate the level of quality requested for the new I P flow in addition to maintaining the level of quality for the I P flows already allocated to the bearer (block 4.8).

As used herein, the term "circuitry" or "processing circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. Fig. 5 illustrates, for one embodiment, example components of an electronic device 500. In some embodiments, the electronic device 500 may be a user equipment (UE), an eNB, or some other appropriate electronic device. In some embodiments, the electronic device 500 may include application circuitry 502, baseband circuitry 504, Radio Frequency (RF) circuitry 506, front-end module (FEM) circuitry 508, and one or more antennas 560, coupled together at least as shown.

The application circuitry 502 may include one or more application processors. For example, the application circuitry 502 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/or may include memory/storage, such as storage medium 503, and may be configured to execute instructions stored in the memory/storage to enable various applications and/or operating systems to run on the system. In some implementations, storage medium 503 may include a non-transitory computer-readable medium. Application circuitry 502 may, in some embodiments, connect to or include one or more sensors, such as environmental sensors, cameras, etc.

Baseband circuitry 504 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 504 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 506 and to generate baseband signals for a transmit signal path of the RF circuitry 506. Baseband processing circuitry 504 may interface with the application circuitry 502 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 506. For example, in some embodiments, the baseband circuitry 504 may include a second generation (2G) baseband processor 504a, third generation (3G) baseband processor 504b, fourth generation (4G) baseband processor 504c, and/or other baseband processor(s) 504d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 5G, etc.). The baseband circuitry 504 (e.g., one or more of baseband processors 504a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 506. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some implementations, baseband circuitry 504 may be associated with storage medium 503 or with another storage medium.

In some embodiments, modulation/demodulation circuitry of the baseband circuitry 504 may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 504 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments. In some embodiments, the baseband circuitry 504 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (E-UTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and/or radio resource control (RRC) elements. A central processing unit (CPU) 504e of the baseband circuitry 504 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 504f. The audio DSP(s) 504f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.

The baseband circuitry 504 may further include memory/storage 504g. The

memory/storage 504g may be used to load and store data and/or instructions for operations performed by the processors of the baseband circuitry 504. Memory/storage for one embodiment may include any combination of suitable volatile memory and/or non-volatile memory. The memory/storage 504g may include any combination of various levels of memory/storage including, but not limited to, read-only memory (ROM) having embedded software instructions (e.g., firmware), random access memory (e.g., dynamic random access memory (DRAM)), cache , buffers, etc. The memory/storage 504g may be shared among the various processors or dedicated to particular processors.

Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some

embodiments, some or all of the constituent components of the baseband circuitry 504 and the application circuitry 502 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 504 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 504 may support communication with an evolved universal terrestrial radio access network (E-UTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 504 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 506 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 506 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 506 may include a receive signal path which may include circuitry to down-convert RF signals received from the FE circuitry 508 and provide baseband signals to the baseband circuitry 504. RF circuitry 506 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 504 and provide RF output signals to the FEM circuitry 508 for transmission.

In some embodiments, the RF circuitry 506 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 506 may include mixer circuitry 506a, amplifier circuitry 506b and filter circuitry 506c. The transmit signal path of the RF circuitry 506 may include filter circuitry 506c and mixer circuitry 506a. RF circuitry 506 may also include synthesizer circuitry 506d for synthesizing a frequency for use by the mixer circuitry 506a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 506a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 508 based on the synthesized frequency provided by synthesizer circuitry 506d. The amplifier circuitry 506b may be configured to amplify the down-converted signals and the filter circuitry 506c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals.

Output baseband signals may be provided to the baseband circuitry 504 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals. In some embodiments, mixer circuitry 506a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 506a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 506d to generate RF output signals for the FEM circuitry 508. The baseband signals may be provided by the baseband circuitry 504 and may be filtered by filter circuitry 506c. The filter circuitry 506c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upconversion respectively. In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 506 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 504 may include a digital baseband interface to communicate with the RF circuitry 506.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry 506d may be a fractional-N synthesizer or a fractional N/ +6 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 506d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 506d may be configured to synthesize an output frequency for use by the mixer circuitry 506a of the RF circuitry 506 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 506d may be a fractional N N+6 synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO). Divider control input may be provided by either the baseband circuitry 504 or the applications processor 502 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 502.

Synthesizer circuitry 506d of the RF circuitry 506 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+6 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 506d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 506 may include an IQ/polar converter.

FEM circuitry 508 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 560, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 506 for further processing. FEM circuitry 508 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 506 for transmission by one or more of the one or more antennas 560.

In some embodiments, the FEM circuitry 508 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 506). The transmit signal path of the FEM circuitry 508 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 506), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 560. In some embodiments, the electronic device 500 may include additional elements such as, for example, memory/storage, display, camera, sensors, and/or input/output (I/O) interface. In some embodiments, the electronic device of Fig. 5 may be configured to perform one or more methods, processes, and/or techniques such as those described herein.

Fig. 6 is a diagram of example components of a device 600. Each of the devices illustrated in Figs. 1 , 2, and 4 may include one or more devices 600. In some embodiments, device 600 may be an example of a PGW device, a PCRF device, and/or a P-CSCF device. Device 600 may include processor circuitry 610, memory and/or storage medium 620, communication interface 630, communication circuitry 640, input circuitry 650, and output circuitry 660. In another implementation, device 600 may include additional, fewer, different, or differently arranged components. Additionally, one or more of the components of device 600 may be an example of circuitry, network interfaces, etc., described herein.

Processor circuitry 610 may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Memory and/or storage medium 620 may include any type of dynamic storage device that may store information and instructions for execution by processor 610, and/or any type of non-volatile storage device that may store information for use by processor 610.

Communication interface 630 may include any transceiver-like mechanism that enables device 600 to communicate with other devices and/or systems. For example, communication interface 630 may include an Ethernet interface, an optical interface, a coaxial interface, or the like. Communication interface 630 may include a wireless communication device, such as an infrared (IR) receiver, a cellular radio, a Bluetooth radio, or the like. In some embodiments, device 600 may include more than one communication interface 630. For instance, device 600 may include an optical interface and an Ethernet interface.

Communication circuitry 640 may include one or more communication paths (e.g., internal busses) that permit communication among the components of device 600. Input circuitry 650 may include a mechanism that permits an operator to input information to device 600, such as a keyboard, a keypad, a button, a switch, etc. Output component 660 may include a mechanism that outputs information to the operator, such as a display, one or more light emitting diodes (LEDs), a speaker, etc.

Device 600 may perform certain operations described above. Device 600 may perform these operations in response to processor circuitry 610 executing software instructions stored in a computer-readable medium, such as memory and/or storage medium 620. A computer- readable medium may be defined as a non-transitory memory device. A memory device may include space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into memory and/or storage medium 620 from another computer-readable medium or from another device. The software instructions stored in memory and/or storage medium 620 may cause processor 610 to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

A number of examples, relating to implementations of the techniques described above, will next be given.

In a first example, a P-CSCF device may comprise a first network interface devices to communicate with UEs via a RAN of a wireless telecommunications network; a second network interface to communicate with a PCRF device of the wireless telecommunications network; and circuitry to: receive a SIP message that includes a first indication that the SIP message originated from a remote UE, establish or modify an Rx session with the PCRF, and

communicate, to the PCRF, a request message, via the Rx session, that includes a description of at least one media flow, corresponding to a communication session of the remote UE.

In example 2, the subject matter of example 1 may further include wherein the SIP message includes a SIP REGISTER message.

In example 3, the subject matter of example 1 , or any of the examples herein, may further include wherein the SIP message includes a SIP INVITE message.

In example 4, the subject matter of example 1 , or any of the examples herein, may further include wherein the request message includes an [Rx] AAR message.

In example 5, the subject matter of example 1 , or any of the examples herein, may further include wherein the request message includes a third indication of the quality for the at least one media flow.

In example 6, the subject matter of example 1 , or any of the examples herein, may further include wherein the third indication includes at least one of: a QoS parameter, a QCI, an allocation and ARP, or a GBR.

In a seventh example, a PCRF device may comprise a plurality of transmission ports; and circuitry to: establish a first control session, corresponding to a first UE, with a PDN PGW of a wireless telecommunications network; establish a second control session, corresponding to a second UE, with a P-CSCF of an I MS of the wireless telecommunications network; map the first control session to the second control session based on the first UE operating as a relay device between the second UE and the wireless telecommunications network; receive a request, from the second UE, via the P-CSCF, to establish a call between the second UE and a third UE; and cause the PGW to bind the call to a bearer associated with the first UE.

In example 8, the subject matter of example 7 may further include wherein the call is bound to the bearer based on a QoS for the call and a QoS of another call already bound to the bearer.

In example 9, the subject matter of example 7, or any of the examples herein, may further include wherein the circuitry is to cause the PGW to increase network resources allocated to the bearer based on a QoS for the call.

In example 10, the subject matter of example 7, or any of the examples herein, may further include wherein the first communication session corresponds to a Gx interface between the PCRF and the PGW and the second communication session corresponds to a Rx interface between the PCRF and the P-CSCF.

In example 1 1 , the subject matter of example 7, or any of the examples herein, may further include wherein the first control session is established as part of a PDN connection being established between the first UE and the wireless telecommunications network and the second control session is established as part of the second UE registering with the IMS.

In example 12, the subject matter of example 7, or any of the examples herein, may further include wherein, to cause the PGW to bind the call to the bearer, the circuitry is to cause the PGW to: determine whether a network bearer, associated with another call having a QoS similar to a QoS of the call, has been allocated to the first UE; when the network bearer has been allocated to the first UE, bind the call to the network bearer; and when the network bearer has not been allocated to the first UE, allocate a new network bearer, based on the QoS of call, to the first UE, and bind the call to the new network bearer.

In example 13, the subject matter of example 1 or 7, or any of the examples herein, may further include wherein the bearer includes an EPS bearer.

In a fourteenth example, a computer readable medium may contain program instructions for causing one or more processors to: receive a SIP message that includes a first indication that the SIP message originated from a remote UE, establish or modify an Rx session with the PCRF, and communicate, to the PCRF, a request message, via the Rx session, that includes a description of at least one media flow, corresponding to a communication session of the remote UE.

In example 15, the subject matter of example 14, may further include wherein the SIP message includes a SIP REGISTER message.

In example 16, the subject matter of example 14, or any of the examples herein, may further include wherein the SIP message includes a SIP INVITE message.

In example 17, the subject matter of example 14, or any of the examples herein, may further include wherein the request message includes an [Rx] AAR message.

In example 18, the subject matter of example 14, or any of the examples herein, may further include wherein the request message includes a third indication of the quality for the at least one media flow.

In example 19, the subject matter of example 14, or any of the examples herein, may further include wherein the third indication includes at least one of: a QoS parameter, a QCI, an ARP, or a GBR.

In a twentieth example, a P-CSCF device may comprise: means for receiving a Session

Initiation Protocol (SIP) message that includes a first indication that the SIP message originated from a remote UE; means for establishing or modifying an Rx session with the PCRF; and means for communicating, to the PCRF, a request message, via the Rx session, that includes a description of at least one media flow, corresponding to a communication session of the remote UE.

In example 21 , the subject matter of example 20 may further include wherein the SIP message includes a SIP REGISTER message.

In example 22, the subject matter of example 20, or any of the examples herein, may further include wherein the SIP message includes a SIP INVITE message.

In example 23, the subject matter of example 20, or any of the examples herein, may further include wherein the request message includes an [Rx] AAR message.

In a twenty-fourth example, one or more network devices may comprise: one or more network interface devices to communicate with user equipment devices (UEs) via a radio access network (RAN) of a wireless telecommunications network; and circuitry to: receive a request, originating from a first UE, via a second UE, to establish a call between the first UE and a third

UE; determine, based on the request, a level of quality associated with implementing the call; determine whether a network bearer, associated with another call of a similar level of quality as the level of quality associated with implementing the call, has been allocated the second UE; when the network bearer has been allocated to the second UE, bind the call to the network bearer, and modify network resources allocated to the network bearer based on the level of quality associated with implementing the call; and when the network bearer has not been allocated to the second UE, allocate a new network bearer, based on the level of quality associated with implementing the call, to the second UE, and bind the call to the new network bearer. In example 25, the subject matter of example 24, or any of the examples herein, may further include wherein the circuitry is to: prior to the request to establish the call, establish a control session for the second UE via a Gx interface of the wireless telecommunications network, receive a request, originating from the first UE and via the second UE, to register the first UE with an I MS of the wireless telecommunications network, establish a control session, for the first UE, via an Rx interface of the wireless telecommunications network, and map the control session via the Gx interface with the control session via the Rx session.

In example 26, the subject matter of example 24, or any of the examples herein, may further include wherein the request to register the first UE includes an indication that the first UE is operating as a remote UE.

In example 27, the subject matter of example 24, or any of the examples herein, may further include wherein, to map the control session of the Gx interface with the control session of the Rx session, the circuitry is to: identify an IPv6 prefix, associated with the first UE, based on an IPv6 address associated with the second UE.

In example 28, the subject matter of example 24, or any of the examples herein, may further include wherein: the Gx interface includes a communications interface between a PDN PGW and a PCRF of an EPC, and the Rx interface includes a communications interface between the PCRF of the EPC and a P-CSCF of the IMS.

In example 29, the subject matter of example 24, or any of the examples herein, may further include wherein the request to establish the call includes an indication that first UE is operating as a remote UE.

In the preceding specification, various embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

For example, while series of signals have been described with regard to Fig. 4, the order of the signals may be modified in other implementations. Further, non-dependent signals may be performed in parallel.

It will be apparent that example aspects, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects should not be construed as limiting. Thus, the operation and behavior of the aspects were described without reference to the specific software code—it being understood that software and control hardware could be designed to implement the aspects based oh the description herein.

Further, certain portions may be implemented as "logic" that performs one or more functions. This logic may include hardware, such as an application-specific integrated circuit ("ASIC") or a field programmable gate array ("FPGA"), or a combination of hardware and software.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to be limiting. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.

No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. An instance of the use of the term "and," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Similarly, an instance of the use of the term "or," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Also, as used herein, the article "a" is intended to include one or more items, and may be used interchangeably with the phrase "one or more." Where only one item is intended, the terms "one," "single," "only," or similar language is used.

Claims

WHAT IS CLAIMED I S:

1 . A Proxy Call Session Control Function (P-CSCF) device, comprising:

a first network interface devices to communicate with user equipment devices (UEs) via a radio access network (RAN) of a wireless telecommunications network;

a second network interface to communicate with a Policy and Charging Rules Function (PCRF) device of the wireless telecommunications network; and

circuitry to:

receive a Session Initiation Protocol (SI P) message that includes a first indication that the SIP message originated from a remote UE,

establish or modify an Rx session with the PCRF, and

2. The P-CSCF device of claim 1 , wherein the SI P message includes a SI P

REGISTER message.

3. The P-CSCF device of claim 1 , wherein the SI P message includes a SI P INVITE message.

4. The P-CSCF device of claim 1 , wherein the request message includes an [Rx] Authentication-Authorization Request (AAR) message.

5. The P-CSCF device of claim 1 , wherein the request message includes a third indication of the quality requirements of the at least one media flow.

6. The P-CSCF device of claim 1 , wherein the third indication includes at least one of:

a quality of service (QoS) parameter,

a QoS class identifier (QCI),

an allocation and retention priority (ARP), or

a guaranteed bit rate (GBR).

7. A Policy and Charging Rules Function (PCRF) device, comprising:

a plurality of transmission ports; and

circuitry to:

establish a first control session, corresponding to a first user equipment device (UE), with a Packet Data Network (PDN) Gateway (PGW) of a wireless

telecommunications network;

establish a second control session, corresponding to a second UE, with a Proxy Call Session Control Function (P-CSCF) of an Internet Protocol (I P) multimedia subsystem (IMS) of the wireless telecommunications network;

map the first control session to the second control session based on the first UE operating as a relay device between the second UE and the wireless telecommunications network;

receive a request, from the second UE, via the P-CSCF, to establish a call between the second UE and a third UE; and

cause the PGW to bind the call to a bearer associated with the first UE.

8. The PCRF of claim 7, wherein the call is bound to the bearer based on a quality of service (QoS) required by the call and a QoS of another call already bound to the bearer.

9. The PCRF of claim 7, wherein the circuitry is to:

cause the PGW to increase network resources allocated to the bearer based on a QoS required by the call.

10. The PCRF of claim 7, wherein:

the first communication session corresponds to a Gx interface between the PCRF and the PGW, and

the second communication session corresponds to a Rx interface between the PCRF and the P-CSCF.

1 1. The PCRF of claim 7, wherein:

the first control session is established as part of a packet data network (PDN) connection being established between the first UE and the wireless telecommunications network, and

the second control session is established as part of the second UE registering with the

IMS.

12. The PCRF of claim 7, wherein, to cause the PG W to bind the call to the bearer, the circuitry is to:

cause the PGW to:

determine whether a network bearer, associated with another call having a quality of service (QoS) similar to a QoS of the call, has been allocated to the first UE;

when the network bearer has been allocated to the first UE,

bind the call to the network bearer; and

when the network bearer has not been allocated to the first UE,

allocate a new network bearer, based on the QoS of call, to the first UE, and

bind the call to the new network bearer.

13. A device as in claims 1 or 7, wherein the bearer includes an Evolved Packet System (EPS) bearer.

14. A computer readable medium containing program instructions for causing one or more processors to:

receive a Session Initiation Protocol (SIP) message that includes a first indication that the SIP message originated from a remote UE,

establish or modify an Rx session with the PCRF, and

1 5. The compute readable medium of claim 14, wherein the SIP message includes a SIP REGISTER message.

16. The compute readable medium of claim 14, wherein the SIP message includes a SIP INVITE message.

1 7. The compute readable medium of claim 14, wherein the request message includes an [Rx] Authentication-Authorization Request (AAR) message.

1 8. The compute readable medium of claim 14, wherein the request message includes a third indication of the quality requirements of the at least one media flow.

19. The compute readable medium of claim 14, wherein the third indication includes at least one of:

a quality of service (QoS) parameter,

a QoS class identifier (QCI),

an allocation and retention priority (ARP), or

a guaranteed bit rate (GBR).

20. One or more network devices, comprising:

one or more network interface devices to communicate with user equipment devices (UEs) via a radio access network (RAN) of a wireless telecommunications network; and

circuitry to:

receive a request, originating from a first UE, via a second UE, to establish a call between the first UE and a third UE;

determine, based on the request, a level of quality associated with implementing the call;

determine whether a network bearer, associated with another call of a similar level of quality as the level of quality associated with implementing the call, has been allocated the second UE;

when the network bearer has been allocated to the second UE,

bind the call to the network bearer, and

modify network resources allocated to the network bearer based on the level of quality associated with implementing the call; and when the network bearer has not been allocated to the second UE, allocate a new network bearer, based on the level of quality associated with implementing the call, to the second UE, and

bind the call to the new network bearer.

21 . The one or more network devices of claim 20, wherein the circuitry is to:

prior to the request to establish the call,

establish a control session for the second UE via a Gx interface of the wireless telecommunications network, receive a request, originating from the first UE and via the second UE, to register the first UE with an Internet Protocol (I P) multimedia subsystem (I MS) of the wireless telecommunications network,

establish a control session, for the first UE, via an Rx interface of the wireless telecommunications network, and

map the control session via the Gx interface with the control session via the Rx session.

22. The one or more network devices of claim 20, wherein the request to register the first UE includes an indication that the first UE is operating as a remote UE.

23. The one or more network devices of claim 20, wherein, to map the control session of the Gx interface with the control session of the Rx session, the circuitry is to:

identify an IPv6 prefix, associated with the first UE, based on an IPv6 address associated with the second UE.

24. The one or more network devices of claim 20, wherein:

the Gx interface includes a communications interface between a Packet Data Network (PDN) Gateway (PGW) and a Policy and Charging Rules Function (PCRF) of an Evolved Packet Core (EPC), and

the Rx interface includes a communications interface between the PCRF of the EPC and a Proxy Call Session Control Function (P-CSCF) of the IMS.

25. The one or more network devices of claim 20, wherein the request to establish the call includes an indication that first UE is operating as a remote UE.