Patent Description:
Modern telecommunications networks such as cellular telephone networks can support a variety of types of session, such as voice, video, or messaging. Second-generation (<NUM>) and third-generation (<NUM>) cellular networks such as Global System for Mobile Communications (GSM) networks or Universal Mobile Telecommunications System (UMTS) networks generally carry streaming media over circuit-switched (CS) connections. Fourth-generation (<NUM>) cellular networks such as Long Term Evolution (LTE) (including LTE-Advanced) networks and fifth-generation (<NUM>) cellular networks such as the 3GPP <NUM> System generally carry streaming media over packet-switched (PS) connections. Many cellular carriers operate wireless access networks spanning multiple technology generations due to the substantial infrastructure investment needed to expand cellular networks. Due to differences in network deployment and the radio environment, a terminal may sometimes hand over from a higher-generation access network to a lower-generation access network.

The document <CIT> discloses the assignment of a default EPS bearer ID and the transmission of a Create Session Request message that includes the default EPS bearer ID.

There is provided a telecommunication device according to the claims.

For brevity of illustration, in the diagrams herein, an arrow beginning with a diamond connects a first component or operation (at the diamond end) to at least one second component or operation that is or can be, in at least one example, included in the first component or operation.

This disclosure describes, in part, a telecommunications network configured to implement bearer selection for bearers used by a terminal. Bearer selection can include assignment or management of bearers, e.g., when they are created or terminated, or at handover or other changes of state of a terminal. A bearer is an identified logical connection for conveying data in a manner determined by the bearer. For example, a bearer can have particular Quality of Service (QoS) or throughput (bits per second, bps) characteristics. A terminal can have one or more bearers open concurrently via a single radio connection.

Examples of bearers can include, in LTE, data radio bearers (DRBs) between the terminal and an eNodeB, S1 bearers between the eNodeB and a Serving Gateway (S-GW), or Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Radio Access Bearers (E-RABs) between the terminal and the S-GW. Other examples of bearers can include 3GPP <NUM> DRBs between a terminal and a gNodeB, <NUM> NG-C bearers between a gNodeB and an Access Management Function (AMF), or <NUM> NG-U bearers between a gNodeB and a User Plane Function (UPF). A bearer via one or more network(s) between a first node or device and a second node or device can include or consist of other bearers, each spanning part of a path through the network between the first node or device and the second node or device. For example, an E-RAB can include or consist of a DRB and a corresponding S <NUM> bearer. In some examples, a bearer can carry a service data flow (SDF, 3GPP <NUM>) having defined flow characteristics, or an aggregate of SDFs. In some examples, a bearer carries traffic for a particular packet data network (PDN), e.g., the Internet or an Internet Protocol (IP) Multimedia Subsystem (IMS), and that traffic includes multiple SDFs, e.g., one for email and another for streaming video.

In some examples, a first access network can support one number of bearers per terminal, and a second, different access network can support fewer bearers per terminal. During handover from the first access network to the second access network, some of the bearers allocated while attached to the first access network will be terminated ("dropped" or "deallocated"). In some prior schemes, the selection of which bearers are dropped is not correlated with priority values of those bearers (e.g., network-defined priority values or user-assigned priority values). Since bearer selection is not correlated with priority values, bearer dropping may result in a streaming-media session being terminated or another negative user experience. In some examples herein, bearer selection permits retaining higher-priority bearers during handover, which can reduce the probability of a negative user experience. In some examples herein, bearer selection permits retaining more active bearers, e.g., by terminating Short Message Service (SMS) or other asynchronous, low-volume bearers. This can reduce the probability of loss of data and negative effects on the user experience.

Bearer selection can be performed at the time of bearer allocation, e.g., periodically or when the terminal requests a network service, or at the time of deallocation, e.g., due to handover. Bearer selection can be based on the service(s) or mix of service(s) that a terminal is currently using or wishes to use. Reducing the number of bearers in use (e.g., at the time of handover) is referred to herein for brevity as "pruning" the set of bearers in use.

As used herein, a "terminal" is a communication device, e.g., a cellular telephone or other user equipment (UE), configured to perform, or intercommunicate with systems configured to perform, techniques described herein. Terminals can include, e.g., wireless or wired voice- or data- communication devices. A terminal can be a device that includes a user interface (e.g., as does a smartphone), or can be a device that does not include a user interface. For example, a streaming server configured to provide audio or visual content on demand can be a terminal. Such a terminal may not include a user interface, and may instead respond to other terminals that form queries and send those queries to the server in response to actions taken via interfaces at those other terminals. A terminal can be, e.g., a cellular phone, smartphone, tablet computer, personal digital assistant (PDA), personal computer (PC), laptop computer, media center, work station, etc..

The terms "session" and "communication session" as used herein include a communications path for bidirectional exchange of data among two or more terminals. Example sessions include voice and video calls, e.g., by which human beings converse; data communication sessions, e.g., between two electronic systems or between an electronic system and a user-interface device in use by a human being; or a Rich Communication Suite (RCS) session. Sessions can be carried, e.g., by cellular or data networks, e.g., LTE or IEEE <NUM> (WIFI). Other examples of networks are discussed below.

Subsection headers in this Detailed Description are solely for convenience in reading. No limitations are implied by the presence or arrangement of the subsection headers, or by the separation of features between those subsections. Some examples include features from only one subsection. Some examples include features from more than one subsection.

<FIG> illustrates an example telecommunications network <NUM> and shows an overview of nodes and devices involved in provision of bearer-selection services to terminals. The telecommunications network <NUM> includes terminals <NUM>(<NUM>)-<NUM>(N) (individually or collectively referred to herein with reference <NUM>), N≥<NUM>. A terminal <NUM> may be or include a cellular phone or other type of terminal such as those described above. Terminal <NUM> can be configured to originate or receive communications sessions.

In some examples, terminal <NUM> can communicate, e.g., via a first access network <NUM> of a first class or a second access network <NUM> of a second, different class. Terminal <NUM> may participate in a handover between first access network <NUM> and second access network <NUM>, e.g., as a user moves in and out of coverage areas of individual access networks <NUM> or <NUM>. A single-connectivity (or single-radio, SR) terminal <NUM> can communicate via one access network <NUM>, <NUM> at a time. A dual-connectivity (dual-radio, DR) terminal <NUM> can communicate concurrently via both access network <NUM> and access network <NUM>, as shown by the stippled lines. Some examples herein relate to SR terminals <NUM>.

Classes can relate to types of network (e.g., PS vs. CS) or to service levels provided by networks to a subscriber. The term "class" does not imply that either of the first class or the second class is superior to the other. Examples of a first class and a second, different class are given in Table <NUM>. In some examples, the class of a network depends on the subscriber or terminal <NUM>. For example, a particular subscriber or terminal <NUM> may only be authorized to use a certain number of bearers on second access network <NUM>, even if second access network <NUM> permits other subscribers or terminals <NUM> to use more than the certain number of bearers.

In the illustrated example, first access network <NUM> includes a first entry node <NUM>, e.g., a <NUM> gNodeB, and a first access node <NUM>, e.g., a <NUM> Access and Mobility Management Function (AMF). Second access network <NUM> includes a second entry node <NUM>, e.g., an LTE eNodeB, and a second access node <NUM>, e.g., an LTE mobility management entity (MME). Other examples of access nodes include a GSM mobile switching center (MSC) server (MSS). Terminal <NUM> can communicate via the respective entry nodes <NUM>, <NUM> with the respective access nodes <NUM>, <NUM>. The first access node <NUM> and the second access node <NUM> are examples of access nodes or devices that can control or modify communications with terminal <NUM> via access network(s) <NUM> or <NUM>.

A handover between access networks can include, for example, a handover from packet-switched first access network <NUM> to circuit-switched second access network <NUM>. However, handover is not limited to that example. For example, an SR terminal <NUM> can be handed over from a <NUM> access network to an LTE access network, or in general between a first access network of a first class and a second access network, e.g., of the first class or of a second, different class (e.g., PS to CS or vice versa). Example network classes may include cellular networks, WIFI networks carrying voice-over-Internet-Protocol (VoIP) communication sessions, wireline networks such as Ethernet, or wide-area networks such as those used for communications via satellites.

The terminal <NUM> can be configured to initiate or receive a communication session, such as a voice call, a video call, or another sort of synchronous communication. Initiation of such communications may involve communication clients and Session Initiation Protocol (SIP, RFC <NUM>) clients communicatively connected with components of the telecommunications network, e.g., session-control node <NUM>. In various embodiments, the session-control node <NUM> represents components of an IMS core network. Session-control node <NUM> can be part of an application network <NUM>, e.g., an IMS network or other network providing services to terminal <NUM>. Application network <NUM> can also be referred to as an "upper-level" network that uses the services provided by access networks <NUM>, <NUM> to communicate with terminals <NUM>. Network <NUM> can include or be connected with any number of access networks <NUM>, <NUM> or any number of application networks <NUM>.

In some examples, access nodes <NUM>, <NUM>, or session-control node <NUM>, can communicate with an information server <NUM> to retrieve information about terminals <NUM> or subscribers to the telecommunications network <NUM>. For example, information server <NUM> can be or include an LTE HSS or HLR, or a <NUM> User Data Management (UDM) function or User Data Repository (UDR). Although shown as separate from access networks <NUM> and <NUM> and from application network <NUM>, information server <NUM> can be part of any of those, or can communicate with ones of those of which it is or is not part, in various examples.

Each of the first access node <NUM>, the second access node <NUM>, and the session-control node <NUM>, may each be or include a server or server farm, multiple, distributed server farms, a mainframe, a work station, a PC, a laptop computer, a tablet computer, an embedded system, or any other sort of device or devices. In one implementation, one or more of first access node <NUM>, the second access node <NUM>, and the session-control node <NUM> may represent a plurality of computing devices working in communication, such as a cloud-computing node cluster. Also, the first access node <NUM>, the second access node <NUM>, and the session-control node <NUM> may each be or include nodes or devices of a telecommunications network. Examples of such components are described below with reference to <FIG>.

As noted above, SIP can be used to establish and manage communication sessions. SIP is an IP-based protocol, so terminal <NUM> exchanges SIP messages via an IP link with session-control node <NUM>. To establish IP connectivity via a <NUM> access network <NUM>, terminal <NUM> sends a Service Request message to access network <NUM>, e.g., to a gNodeB of a <NUM> access network. The gNodeB communicates with the AMF to obtain an IP address for terminal <NUM>. The gNodeB can also obtain other information, e.g., the IP address of a session-control node <NUM>. Session-control node <NUM> can include, e.g., a P-CSCF via which terminal <NUM> can access IMS services. The gNodeB responds to terminal <NUM> with the requested information. Terminal <NUM> is then able to communicate via IP with session-control node <NUM> or other IP-connected nodes or devices.

Session-control services are generally provided by session-control node <NUM> independently of the class of access network(s) used for any particular communication session. This permits providing consistent session-control services between, e.g., PS and CS terminals, or throughout a communication session when one party leaves a PS coverage area and hands over to a CS access network. Similarly, access-network selection, a component of bearer selection, is generally performed with respect to the radio characteristics of each available access network <NUM>, <NUM>, without regard to the types of sessions for which the communication link will be used.

However, a terminal <NUM> communicating via one access network may be using more network resources, e.g., bearers, than another access network will support. Because of motion between cells, overload of cells, or other factors, terminal <NUM> may be required to change access networks at times not under the control of terminal <NUM>. Terminal <NUM> may, therefore, not be able to deallocate bearers on its own initiative before handover. Some examples therefore deallocate bearers based at least in part on information about which services should be prioritized, e.g., from the user's standpoint.

In some examples, the first access network <NUM> or the second access network <NUM> may be any sort of access network, such as a GSM or UMTS network; a universal terrestrial radio network (UTRAN) or an Enhanced Data rates for GSM Evolution (EDGE) radio access network (GERAN); an E-UTRAN; a 3GPP <NUM> access network; a WIFI (IEEE <NUM>) or other LAN access network; or a satellite or terrestrial wide-area access network such as a wireless microwave access (WIMAX) network. In some examples, the first access network <NUM> or the second access network <NUM> may include a base station (an eNodeB or gNodeB), as well as a radio network controller (RNC). In some examples, the first access network <NUM> or the second access network <NUM> may use any sort of air interface, such as a code division multiple access (CDMA), time division multiple access (TDMA), or frequency division multiple access (FDMA) air interface. In some examples, the first access network <NUM> may provided packet-switched connections and the second access network <NUM> may provide circuit-switched connections. In some examples, the first access network <NUM> may be a packet-switched cellular class of access network and the second access network <NUM> may be a packet-switched local-area-network class of access network. Examples of LAN access networks can include WIFI and IEEE <NUM>. <NUM> (BLUETOOTH). In some examples, access networks <NUM>, <NUM> may include any network configured to transport IP packets, e.g., IPv4, IPv6, or any other evolution of an IP-based technology.

In some examples, a non-cellular network can carry voice traffic using VoIP or other technologies as well as data traffic, or a cellular network can carry data packets using HSPA, LTE, or other technologies, as well as voice traffic. Some cellular networks carry both data and voice in a packet-switched format. For example, many LTE networks carry voice traffic in data packets according to the voice-over-LTE (VoLTE) standard.

In some examples, wired access networks may be used, exclusively or in combination with wireless access networks. Examples of wired access networks include Plain Old Telephone Service, POTS, or Public Switched Telephone Network, PSTN, lines, optical (e.g., Synchronous Optical NETwork, SONET) technologies, Asynchronous Transfer Mode (ATM), and other network technologies, e.g., configured to transport IP packets. In some examples, the telecommunications network <NUM> can include, or be communicatively connected with, an interworking function (IWF) or other node or device configured to bridge networks, e.g., LTE, <NUM>, and POTS networks. In some examples, the IWF can bridge Signaling System <NUM> (SS7) traffic from the PSTN into the telecommunications network <NUM>, e.g., permitting PSTN customers to originate sessions with cellular customers and vice versa.

As used herein, a message "sent to," "transmitted to," or "transmitted toward" a destination, or similar terms, can be sent directly to the destination, or can be sent via one or more intermediate network nodes or devices to the destination. Those intermediate network nodes or devices can include access nodes <NUM>, <NUM>. Similarly, a message "received from" a destination can be received directly from the destination, or can be received via one or more intermediate network nodes or devices from the destination. A message passing through one or more intermediate network nodes or devices can be modified by those network nodes or devices, e.g., by adding or removing framing, by changing routing information, or by changing a presentation of at least part of the message, e.g., from a SIP start-line to a SIP header or vice versa. As used herein, a "reply" message is synonymous with a "response" message. The term "reply" is used for clarity, e.g., when discussing reply messages sent in response to the receipt of messages.

<FIG> illustrates an example telecommunications network <NUM>. The illustrated blocks represent network functions that can be implemented as standalone device(s), or combined with other network functions into a single device or collection of device(s). The nodes, devices, and networks illustrated in <FIG> can be examples of the nodes, devices, and networks illustrated in <FIG> and described above. Accordingly, the descriptions of the nodes, devices, and networks of <FIG> apply to the nodes, devices, and networks of <FIG>. Some examples herein, e.g., in <FIG>, are given in the context of an originating terminal <NUM>. However, this is not limiting. Corresponding techniques and structures can additionally or alternatively be used with destination (or "terminating," "receiving") terminals <NUM>.

Single-radio terminal <NUM> can attach to access networks <NUM> or <NUM> of the telecommunications network <NUM>. In the example shown, access network <NUM> includes a <NUM> PS access network and access network <NUM> includes an LTE PS access network. <NUM> access network <NUM> includes a gNodeB <NUM> that provides connectivity to the <NUM> access network <NUM>. The gNodeB <NUM> is connected with a user-plane function (UPF) <NUM> and with an AMF <NUM>. LTE access network <NUM> includes an eNodeB <NUM>, e.g., a <NUM> base station or other access point, that provides connectivity to the LTE access network <NUM>. The eNodeB <NUM> is connected with a gateway <NUM> ("GW"), e.g., an LTE S-GW or PGW, and an MME <NUM>. Terminal <NUM> can communicate with application network <NUM> via UPF <NUM> or GW <NUM>. AMF <NUM> and MME <NUM> can communicate to carry out bearer selection in various examples described herein. For brevity herein, the term "entry node" refers to a gNodeB <NUM>, eNodeB <NUM>, WIFI access point (AP), or other network device that is the initial node that terminal <NUM> communicates with in order to access the services of a corresponding access network (e.g., a node that transmits radio signals to, or receives radio signals from, terminal <NUM>).

The telecommunications network <NUM> may also include a number of devices or nodes not illustrated in <FIG>. Nonlimiting examples of such devices or nodes include an ATGW, a serving GPRS support node (SGSN), a gateway GPRS support node (GGSN), a policy control rules function (PCRF) node, a session border controller (SBC), or a non-3GPP-access interworking function (N3IWF). Similarly, throughout this disclosure, other nodes or devices can be used in conjunction with listed nodes or devices. For example, a telecommunications network can include many core network nodes or devices, only some of which implement functions described herein for core network nodes or devices.

In the illustrated example, access network <NUM> can support a higher bearer count than access network <NUM>. That is, terminal <NUM> can have more concurrent sessions established when connected to access network <NUM> than when connected to access network <NUM>. During handover <NUM> of terminal <NUM> from access network <NUM> to access network <NUM>, it is necessary to determine which bearers to drop (discontinue communications via) if more are active than access network <NUM> can support. Although <FIG> illustrates a handover from <NUM> to LTE, this is not limiting. Operations described herein with reference to gNodeB <NUM>, UPF <NUM>, AMF <NUM>, eNodeB <NUM>, GW <NUM>, or MME <NUM> can be performed by nodes of networks of other types or classes, e.g., by entry node <NUM>, a gateway of access network <NUM>, access node <NUM>, entry node <NUM>, a gateway of access network <NUM>, and access node <NUM>, respectively.

In some prior schemes, bearers are allocated sequentially, e.g., by the LTE EPC. The lowest available bearer ID (in numerical order) is allocated when a network node or device, e.g., a terminal, requests a bearer. When a terminal moves to an area that supports fewer bearers than are currently in use by that terminal, the bearers with the numerically highest bearer IDs are dropped, e.g., bearers <NUM>-<NUM> when moving from a system capable of supporting <NUM> bearers to an access network capable of supporting only eight bearers. Since the bearers were allocated in the order they were requested, and the order of requests is not under the control of the network, the services that are affected by the dropped bearers may be different at every handover. For example, the bearers (e.g., active services) chosen to be dropped in this scenario may be inconsistent with regard to the priority of the services (higher-priority bearers may be dropped and lower-priority bearers retained). Various examples herein prioritize bearers so that the dropping of bearers is less likely to negatively affect the functioning of the terminal, e.g., the ability of the terminal to provide uninterrupted or substantially uninterrupted services that the user has requested.

<FIG> is a block diagram illustrating a system <NUM> permitting bearer selection according to some implementations. The system <NUM> includes a terminal <NUM> (which can represent terminal <NUM>) communicatively connectable with a server <NUM> via a network <NUM>. The server <NUM> can represent an access node <NUM> or <NUM>, a session-control node <NUM>, or another control system of a telecommunications network configured to perform functions described herein. Server <NUM> can be implemented using dedicated or shared (e.g., cloud) computing hardware. The network <NUM> can include one or more networks, such as a cellular network, e.g., <NUM>, or a non-cellular network, e.g., WIFI. Example network technologies are described above with reference to <FIG>.

The terminal <NUM> can include one or more processors <NUM>, e.g., one or more processor devices such as microprocessors, microcontrollers, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), programmable logic devices (PLDs), programmable logic arrays (PLAs), programmable array logic devices (PALs), or digital signal processors (DSPs). Terminal <NUM> can include one or more computer readable media (CRM) <NUM>, such as semiconductor memory (e.g., random access memory (RAM), solid state drives (SSDs), or the like), disk drives (e.g., platter-based hard drives), another class of computer-readable media, or any combination thereof. The terminal <NUM> can further include a user interface (UI) <NUM>, e.g., including an electronic display device, a speaker, a vibration unit, a touchscreen, or other devices for presenting information to a user and receiving commands from the user. The terminal <NUM> can further include one or more communications interface(s) <NUM>, e.g., radio(s) or other network interface(s), configured to selectively communicate (wired or wirelessly) via the network <NUM>, e.g., via an access network <NUM> or <NUM>.

CRM <NUM> can be used to store data and to store instructions that are executable by the processors <NUM> to perform various functions as described herein. CRM <NUM> can store various classes of instructions and data, such as an operating system, device drivers, program modules, etc. The processor-executable instructions can be executed by the processors <NUM> to perform the various functions described herein. CRM <NUM> can be or include computer-readable storage media. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other semiconductor memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, non-transitory medium which can be used to store the desired information and which can be accessed by the processors <NUM>.

CRM <NUM> can include processor-executable instructions of a client application <NUM>. The client application <NUM>, e.g., a native or other dialer, can permit a user to originate and receive communication sessions, e.g., voice or Unstructured Supplementary Service Data (USSD), associated with the terminal <NUM>. The client application <NUM> can additionally or alternatively include an SMS, RCS, or presence client, or a client of another telephony service offered by the server <NUM>. For example, the client application <NUM> can communicate with entry nodes <NUM>, <NUM> to allocate bearers for network services requested by terminal <NUM> or user thereof.

CRM <NUM> can store identification information <NUM> identifying the terminal <NUM>. The identification information <NUM> can include, e.g., an IMEI of terminal <NUM> or an IMSI identifying the subscriber using terminal <NUM>. CRM <NUM> can store credentials (omitted for brevity) used for access, e.g., to IMS or RCS services. In some examples, CRM <NUM> includes a Subscriber Identity Module (SIM) card providing secure credential storage. CRM <NUM> can store service information <NUM> relating to session types used by terminal <NUM>, e.g., as discussed herein with reference to <FIG>. For example, service information <NUM> can include information of what QoS levels should be requested for what network services.

The server <NUM> can include one or more processors <NUM> and one or more CRM <NUM>. CRM <NUM> can store processor-executable instructions of a bearer-selection module <NUM> or a pruning module <NUM>. The processor-executable instructions of modules <NUM> and <NUM> can be executed by the one or more processors <NUM> to perform various functions described herein. In some examples, server <NUM> can be configured to, e.g., by executing the processor-executable instructions, perform functions described herein with reference to <FIG>.

In some examples, server <NUM> can communicate with (e.g., is communicatively connectable with) terminal <NUM> or other nodes or devices via one or more communications interface(s) <NUM>, e.g., network transceivers for wired or wireless networks, or memory interfaces. Example communications interface(s) <NUM> can include Ethernet or FIBRE CHANNEL transceivers, WIFI radios, or DDR memory-bus controllers (e.g., for DMA transfers to a network card installed in a physical server <NUM>). Communications interface(s) <NUM> can include any of the components described in this paragraph.

In some examples, processor <NUM> and, if required, CRM <NUM>, are referred to for brevity herein as a "control unit. " For example, a control unit can include a CPU or DSP and instructions executable by that CPU or DSP to cause that CPU or DSP to perform functions described herein. Additionally or alternatively, a control unit can include an ASIC, FPGA, or other logic device(s) wired (physically or via blown fuses or logic-cell configuration data) to perform functions described herein. Other examples of control units can include processor <NUM> with, if required, CRM <NUM>.

<FIG> is a dataflow diagram illustrating an example process <NUM> for bearer selection, and related data items. Process <NUM> can be performed, e.g., by a server <NUM> of a telecommunications network <NUM>, e.g., including communications interface <NUM> and at least one processor <NUM>. Server <NUM> can be or include, e. an MME, PDN gateway (PGW), PCRF, AMF, or Session Management Function (SMF), or other access node <NUM>, <NUM> or session-control node <NUM>) In some examples, the server <NUM> includes control unit(s) configured to perform operations described below, e.g., in response to computer program instructions of the bearer-selection module <NUM>.

Network <NUM> can include first wireless access network <NUM> (e.g., <NUM>) having a first entry node <NUM> (e.g., gNodeB <NUM>) and a first access node <NUM> (e.g., AMF <NUM>) communicatively connected with first entry node <NUM>. Network <NUM> can also include second wireless access network <NUM> (e.g., LTE) having a second entry node <NUM> (e.g., eNodeB <NUM>) and a second access node <NUM> (e.g., MME <NUM>) communicatively connected with the second entry node <NUM> and with the first access node <NUM>. In some examples, first wireless access network <NUM> is LTE and second wireless access network <NUM> is <NUM>, and the first access node <NUM> is an MME. Each of nodes <NUM>, <NUM>, <NUM>, and <NUM> can be or include a server <NUM> or process(es) or module(s) running thereon, or other type(s) of control unit(s) to perform the listed functions.

Operations shown in <FIG> and in <FIG>, discussed below, can be performed in any order except when otherwise specified, or when data from an earlier step is used in a later step. For clarity of explanation, reference is herein made to various components shown in <FIG> that can carry out or participate in the steps of the exemplary methods. It should be noted, however, that other components can be used; that is, exemplary method(s) shown in <FIG> are not limited to being carried out by the identified components, and are not limited to including the identified operations or messages.

At <NUM>, the control unit receives a request <NUM> to allocate a bearer. Request <NUM> indicates that terminal <NUM> will be able to use the bearer, once allocated, to receive a corresponding network service via first access network <NUM>. The requested bearer can be, e.g., an LTE DRB, or a <NUM> call-flow identity. The network service is associated with a quality-of-service (QoS) value (QV) and a retention-priority value (RPV). In the illustrated example, request <NUM> includes data indicating the QV <NUM> and the RPV <NUM>.

The QV <NUM> can include, e.g., an LTE QoS Class Identifier (QCI). QCIs can be used to define QoS for individual bearers. For example, voice can have QCI <NUM>, IMS signaling QCI <NUM>, and streaming packet data QCI <NUM>. In some examples, QCI can be changed dynamically. The RPV <NUM> can include, e.g., an Allocation Retention Priority (ARP), which is a relative priority value. In some examples, all services for a given user (e.g., for a given terminal <NUM> at a particular time) share the same ARP (e.g., indicating that that user is a normal user or a priority user).

In some examples, each QCI has an associated priority level (<NUM> v14. <NUM>, §<NUM>. This standardized priority level is used for determining packet priority between SDFs when a network link, e.g., a radio link to terminal <NUM>, cannot satisfy the QoS requirements of the currently active bearers. The QCI-associated priority level does not, alone, permit effectively selecting bearers to prune or retain. For example, terminal <NUM> may be embedded in a vehicle and have open a Vehicle-to-X (V2X) bearer of QCI-associated priority level <NUM> and a live-streaming video bearer of QCI-associated priority level <NUM>, e.g., for a stream being watched by passengers in the vehicle. If the vehicle is on a lightly-loaded, rural road, the user experience will be degraded if the higher-priority-level V2X bearer is retained and the video bearer is pruned, even though the allocated V2X bearer is not actively exchanging data. Various examples herein can permit more effectively determining which bearers to prune.

Pruning bearers as described in various examples herein, e.g., based on data in addition to or instead of the QCI-associated priority level, can improve a user's experience with a terminal. Moreover, many users attempt to solve problems with their terminals by power-cycling those terminals. Therefore, reducing interruptions in the user's sessions can reduce the probability that the user will misattribute session interruptions to the terminal and power-cycle the terminal. The startup process for a terminal involves extra battery drain and extra network load during the network-discovery and initial-attach procedures, compared to standby or low-load operations. Consequently, various herein-described examples that improve bearer pruning can reduce the overall power consumption and network load of a group of terminals.

At <NUM>, the control unit determines a bearer identifier (ID) <NUM> for the network service based at least in part on the QV <NUM> and the RPV <NUM> The bearer identifier can connote or denote a priority of the corresponding bearer. In some examples, as denoted by the open-headed arrow, the control unit further records the bearer assigned bearer ID <NUM> as part of a set <NUM> of bearers allocated by or to terminal <NUM>.

For brevity, throughout this document, bearers with lower-valued bearer IDs <NUM> are described as having higher priority than bearers with higher-valued bearer IDs <NUM>. Additionally or alternatively, higher bearer ID <NUM> values can connote or denote higher priority. Any deterministic relationship between bearer ID <NUM> values and relative bearer priority can be used. Examples are discussed below and with reference to blocks <NUM>, <NUM>, or <NUM>, or Table <NUM>.

Block <NUM> can include determining bearer ID <NUM> further based on at least one supplemental priority value (SPV) <NUM>. SPV <NUM> is different from both the QV <NUM> and the RPV <NUM>. In some examples in which QV <NUM> and the RPV <NUM> (e.g., QCI and ARP) do not together provide enough information to determine the relative priority of bearers (and thus the desired bearer ID <NUM> assignment), the SPV <NUM> can be used to do so. In some examples, the SPV <NUM> comprises at least one of any of the data items listed in Table <NUM>.

At <NUM>, the control unit sends a reply <NUM> comprising the bearer ID <NUM> via the communications interface <NUM>. The reply <NUM> can be transmitted to terminal <NUM>, entry node <NUM>, or other devices or nodes of telecommunications network <NUM>.

In some examples, after block <NUM>, a handover may occur to access network <NUM>. Entry node <NUM>, or another node of access network <NUM>, may need to reduce the number of bearers in use. Accordingly, some time after block <NUM>, entry node <NUM> may perform block <NUM>, <FIG> (shown in phantom). By virtue of the assignment of bearer ID <NUM> at block <NUM>, the bearer with ID <NUM> has already been prioritized with respect to other bearers. Therefore, entry node <NUM> can deallocate the bearer with ID <NUM> (e.g., at block <NUM>, <NUM>, or <NUM>) without having to determine bearer priority. This is discussed in more detail below with reference to <FIG> and <FIG>.

<FIG> illustrates an example process <NUM> performed by server(s) <NUM> of a telecommunications network <NUM> for assigning bearers. In some examples, server(s) <NUM> include control unit(s) configured to perform operations described below, e.g., in response to computer program instructions of the bearer-selection module <NUM>. In some examples, block <NUM> can be preceded by block <NUM>. In some examples, block <NUM> can include blocks <NUM> and <NUM>.

At <NUM>, the control unit determines the SPV <NUM> based at least in part on an APN associated with the service. For example, the control unit can determine a priority flag associated with the APN, e.g., using a lookup table stored at the server(s) <NUM> (e.g., an eNodeB, MME, or PGW), or in a PCRF or other network node. The control unit can then use the priority flag together with the QV <NUM> and RPV <NUM> to determine bearer ID <NUM>. For example, IMS signaling and Internet data may have the same QV <NUM> and RPV <NUM>, but they can be distinguished in priority by the SPV <NUM>.

In some examples, as noted above, all services for a given user have the same RPV <NUM> (ARP). In some examples, at least two bearers in the set <NUM> of bearers have the same QCI. For example, QCI <NUM> can be used for both streaming video services and for Transmission Control Protocol (TCP)-based services such as email or RCS signaling. Various examples herein permit prioritizing, e.g., RCS signaling over streaming video, or vice versa, even if the bearers for both have the same QCI and ARP values. In an example or block <NUM> in which the streaming video is retrieved from the Internet (a first PDN) and the RCS signaling is exchanged with an IMS (a second PDN), the APNs of the two PDNs can be used to determine relative priority. Similarly, APNs or other SPVs <NUM> can be used to determine relative priority between Internet data and Multimedia Messaging Service (MMS) messages, both at QCI <NUM>.

At <NUM>, the control unit determines the bearer ID based at least in part on a second SPV <NUM>. The second SPV <NUM> can include at least one of any of the data items described herein with reference to <FIG>, e.g., those listed in Table <NUM>. In some examples, the second SPV <NUM> is different from the SPV <NUM>; the second SPV <NUM> is different from the QV <NUM>; and the second SPV <NUM> is different from the RPV <NUM>. In some examples, block <NUM> can include block <NUM>.

At <NUM>, the control unit weights the SPV <NUM> more highly than the second SPV <NUM> in determining the bearer ID. For example, the second SPV <NUM> can be used as a tiebreaker when the QV <NUM>, RPV <NUM>, and SPV <NUM> together do not provide enough information to assign a bearer ID <NUM>.

At <NUM>, the control unit triggers a handover of the terminal from first access network <NUM> supporting a first number of bearers to second access network <NUM> supporting a second, lower number of bearers. After block <NUM>, block <NUM> can take place (shown in phantom). Handover can be triggered, e.g., by sending a network-initiated deregistration message to terminal <NUM>; by sending a message to terminal <NUM> to adjust its signal-strength threshold(s); or otherwise as specified in the pertinent standards. Example signal-strength threshold(s) include those applicable to Received Signal Strength Indicator (RSSI) and Reference Signal Received Power (RSRP) measurements.

<FIG> is a dataflow diagram illustrating an example process <NUM> for bearer-set pruning, and related data items. Process <NUM> can be performed, e.g., by a server <NUM> (e.g., an eNodeB, gNodeB, or other entry node <NUM>, <NUM>) of a telecommunications network <NUM>. The telecommunications network <NUM> can include components such as those described herein with reference to process <NUM>. Server <NUM> can include communications interface <NUM> and at least one processor <NUM>. In some examples, server <NUM> includes control unit(s) configured to perform acts described below, e.g., in response to computer program instructions of the pruning module <NUM>. As noted by the phantom representation of blocks <NUM> and <NUM>, block <NUM> can be performed chronologically after block <NUM> or block <NUM>. Some examples herein include a system that performs the functions described herein with reference to both <FIG> and <FIG>; other examples herein include a first system that performs the functions described herein with reference to <FIG> and a separate system that performs the functions described herein with reference to <FIG>.

At <NUM>, the control unit receives an indication <NUM> of a handover of a terminal from a first access network <NUM> to a second access network <NUM>. The control unit can be associated with the second access network <NUM>. As noted above, in some examples, the first access network <NUM> supports a first number of bearers for the terminal <NUM>, and the second access network <NUM> supports a second number of bearers for the terminal <NUM>. The second number is less than the first number.

At <NUM>, the control unit determines that the terminal has allocated a set of bearers comprising more bearers than the second number (e.g., set <NUM>, <FIG>). Therefore, the set of bearers in use by terminal <NUM> needs to be pruned.

<FIG> illustrates an example process <NUM> performed by server(s) <NUM> of a telecommunications network <NUM> for pruning bearers. In some examples, server(s) <NUM> include control unit(s) configured to perform operations described below, e.g., in response to computer program instructions of the bearer-selection module <NUM> or pruning module <NUM>. In some examples, as shown by the dash-dot lines, block <NUM> can be followed by any of blocks <NUM>, <NUM>, or <NUM>.

At <NUM>, the control unit selects a first bearer <NUM> of the set <NUM> of bearers allocated by or to terminal <NUM>. Set <NUM> can represent set <NUM>. The control unit selects the first bearer <NUM> based on respective bearer IDs <NUM> of the bearers in the set <NUM> of bearers. Therefore, the selection of the bearer IDs <NUM>, e.g., at block <NUM>, influences the selection of the first bearer <NUM>.

The control unit also selects the first bearer <NUM> based on a predetermined comparison function <NUM>. Comparison function <NUM> takes as input two different bearer IDs <NUM>, and provides as output a determination of which of the two respective bearers should be terminated before the other or, in general, of which of the two respective bearers has priority over the other. For example, the control unit can select, as the first bearer <NUM>, the bearer having the numerically highest bearer ID <NUM>. The use of comparison function <NUM> to compare two bearer IDs x and y does not imply that either x ory will necessarily be deallocated or otherwise manipulated. However, some examples using comparison function <NUM> or other comparison functions described herein will deallocate or otherwise manipulate one of x ory before the other, based on the result provided by the comparison function <NUM>.

In some examples, comparison function <NUM> can embody a design decision of which bearer IDs <NUM> connote or denote higher-priority bearers, such as voice calls, and which bearer IDs <NUM> connote or denote lower-priority bearers, such as SMS bearers. Comparison function <NUM> can determine, for example, that a bearer having a respective ID <NUM> with a relatively higher numerical value (or session(s) being carried by that bearer) should be terminated before a bearer having a respective ID <NUM> with a relatively lower numerical value (or session(s) being carried by that bearer). Comparison function <NUM> can include any function in closed form that provides a deterministic partial order among the bearer IDs <NUM>. Example comparison functions <NUM> are shown in Table <NUM>. For convenience, without limitation, Python <NUM> notation is used in Table <NUM>, and the two input bearer IDs <NUM> are denoted x and y. The example comparison functions <NUM> in Table <NUM> return the bearer ID having lower priority, e.g., the bearer that should be terminated before the other ("dropFirst," i.e., the first to be dropped of x and y). Additionally or alternatively, a comparison function <NUM> can return the bearer ID having higher priority, e.g., the bearer that should not be terminated before the other.

At <NUM>, the control unit terminates session(s) being carried by the first bearer <NUM>. For example, the control unit can terminate the first bearer <NUM>, and any session(s) being carried on the first bearer <NUM> will be terminated with it. Bearers can be terminated as described in the network standards governing access networks <NUM>, <NUM>. For example, bearers in LTE networks can be terminated using RRCConnectionRelease messages, specified in ETSI TS <NUM><NUM> v13. <NUM>, §<NUM>. Block <NUM> can include advising peer node(s) or device(s) that the session(s) are being dropped, but this is not required. In some examples, block <NUM> only affects the first bearer <NUM> between terminal <NUM> and access networks <NUM>, <NUM>.

In some examples, it may be possible to move bearers instead of or in addition to terminating bearers. Some of these examples use blocks <NUM>, <NUM>, or <NUM>, or <NUM>.

At <NUM>, the control unit determines that a second bearer <NUM> of the second access network <NUM> is unallocated. This can be done according to the network standards governing access network <NUM>.

At <NUM>, the control unit selects a third bearer <NUM> of the set <NUM> of bearers based at least in part on respective bearer IDs <NUM> of the bearers in the set <NUM> of bearers, and the predetermined comparison function <NUM>. For example, the control unit can select a third bearer <NUM> that should be retained, e.g., because it is associated with a priority APN, but that would normally be terminated based solely on its bearer ID. For example, when moving to a second access network <NUM> that only supports eight bearers (with IDs <NUM><NUM>-<NUM>), the control unit can select any bearer with a bearer ID <NUM> ><NUM> as the third bearer <NUM> (or, similarly, as the first bearer <NUM> at block <NUM>, or the fourth bearer <NUM> at block <NUM>).

At <NUM>, the control unit moves session(s) being carried by the third bearer to the second bearer. This can be done according to the network standards governing access networks <NUM>, <NUM>. For example, an LTE RRCConnectionReconfiguration procedure can be used to move the session(s).

At <NUM>, the control unit selects a fourth bearer <NUM> of the set of bearers based on respective bearer IDs <NUM> of the bearers in the set <NUM> of bearers and the predetermined comparison function <NUM>. Examples are discussed herein, e.g., with reference to block <NUM>.

At <NUM>, the control unit terminates session(s) being carried by the fourth bearer <NUM>. Examples are discussed herein, e.g., with reference to block <NUM>. Blocks <NUM> and <NUM> can be performed before, after, or in parallel with either or both of blocks <NUM> and <NUM>. In the illustrated example, block <NUM> is followed by block <NUM>, but that is not limiting. For example, block <NUM> can be followed by block <NUM> (connector "A").

Some examples herein permit rapidly determining which bearers to deallocate. In some examples, the processing required for bearer deallocation in the second access network is reduced, since the control unit can deallocate bearers, e.g., from highest to lowest in order by ID <NUM>, without having to evaluate QVs <NUM>, RPVs <NUM>, or SPVs <NUM>. This can reduce the time required for a handover.

<FIG> is a dataflow diagram illustrating an example process <NUM> for bearer selection, and related data items. Process <NUM> can be performed, e.g., by servers <NUM> of a telecommunication system such as telecommunications network <NUM>. The telecommunication system can include components such as those described herein with reference to process <NUM>. In some examples, server(s) <NUM> include control unit(s) configured to perform operations described below, e.g., in response to computer program instructions of the bearer-selection module <NUM> or pruning module <NUM>. In some examples, operations of process <NUM> are performed by a control unit of a network node such as second entry node <NUM> associated with second access network <NUM>. In some examples, the network node comprises at least one of: an LTE eNodeB, an LTE MME, an LTE PGW, or an LTE PCRF. Process <NUM> can be used, e.g., to prune bearers at the time of handover, even if the bearers have not been assigned priorities or prioritized IDs <NUM> such as in <FIG>.

At <NUM>, the control unit determines that a terminal <NUM> is being handed over from a first access network <NUM> to a second access network <NUM>. The second access network <NUM> supports a predetermined number ("N") of bearers per network terminal <NUM>.

At <NUM>, the control unit determines that the terminal <NUM> has allocated a set <NUM> of bearers comprising more bearers than the predetermined number. Set <NUM> can represent set <NUM> or <NUM>.

At <NUM>, the control unit selects a first bearer <NUM> of the set of bearers. In some examples, the first bearer comprises an LTE DRB. The control unit can select the first bearer <NUM> based at least in part on respective quality-of-service (QoS) values (QVs) <NUM> of at least some bearers of the set <NUM> of bearers, e.g., QCI values or other QVs <NUM>, <FIG>. The control unit can also select the first bearer <NUM> based at least in part on respective retention-priority values (RPVs) <NUM> of at least some bearers of the set <NUM> of bearers, e.g., ARP values or other RPVs <NUM>, <FIG>. Examples are discussed herein, e.g., with reference to blocks <NUM>, <NUM>, <NUM>, or <NUM>.

At <NUM>, the control unit deallocates the first bearer <NUM>. Deallocation can include terminating the first bearer <NUM> or session(s) carried thereby, or moving session(s) from the first bearer <NUM> to other bearer(s). Examples are discussed herein, e.g., with reference to <FIG>.

In some examples, process <NUM> can be used with bearers given IDs <NUM> as discussed herein with reference to <FIG> and <FIG>. Additionally or alternatively, process <NUM> can be used with bearers given IDs randomly, sequentially, or in other ways. Therefore, network nodes of second access network <NUM> that implement process <NUM> can provide improved user experience during handovers, even if first access network <NUM> does not implement process <NUM> or a similar allocation technique.

<FIG> illustrates an example process <NUM> performed by server(s) <NUM> of a telecommunications network <NUM> for pruning bearers, e.g., a network node as discussed herein with reference to <FIG>. In some examples, server(s) <NUM> include control unit(s) configured to perform operations described below, e.g., in response to computer program instructions of the bearer-selection module <NUM> or pruning module <NUM>. In some examples, block <NUM> includes at least one of blocks <NUM>-<NUM>. In some examples, block <NUM> includes block <NUM>, or blocks <NUM> and <NUM>.

At <NUM>, the control unit determines a respective supplemental priority value (SPV) <NUM> of at least one of the bearers in the set <NUM> of bearers based at least in part on an access point name (APN) <NUM> associated with a network service being carried by the respective bearer. Examples are discussed herein, e.g., with reference to block <NUM>.

At <NUM>, the control unit retrieves, from a configuration network node, respective SPV(s) <NUM> for bearer(s) in the set <NUM> of bearers. For example, the control unit can query a PCRF, Policy Control Function (PCF), HSS, MME, PGW, or other node to retrieve a priority flag for a particular bearer or service being carried by that bearer. The bearer can be identified, e.g., by APN or another identifier of a corresponding PDN. In some examples, the configuration network node can store separate SPV <NUM> data, e.g., for each subscriber type.

At <NUM>, the control unit selects the first bearer <NUM> further based at least in part on respective SPVs <NUM> of at least some bearers of the set <NUM> of bearers. Each of the SPVs <NUM> can include an APN, priority flag, or other value(s) of at least one of the data items described herein with reference to <FIG>, e.g., those listed in Table <NUM>. For example, the control unit can select, as the first bearer <NUM>, a bearer that is not associated with a high-priority indication (priority-flag value) in the respective SPV <NUM>. Examples of SPV-based processing are discussed herein, e.g., with reference to blocks <NUM> or <NUM>. Block <NUM> can be used with SPV selection as discussed herein with reference to block <NUM>, block <NUM>, or both, in any combination. For example, at least a first SPV of the SPVs can be determined based on an APN (block <NUM>), and at least a second SPV of the SPVs can be retrieved from a configuration network node (block <NUM>). If the second access network <NUM> supports fewer bearers than the number of bearers indicated as high-priority by their respective SPVs <NUM>, or no low-priority bearers are in use, the control unit can select the first bearer <NUM> from among the high-priority bearers, e.g., based on QV <NUM> or RPV <NUM>.

In some examples, at block <NUM>, the control unit determines bearer ID(s) <NUM> for one or more bearers in the set <NUM> of bearers. The control unit then selects the first bearer <NUM> based on the bearer ID(s) <NUM>, e.g., as discussed herein with reference to block <NUM>. <FIG> describe various examples in which bearer ID(s) <NUM> are selected at the time of allocation and used at the time of deallocation. Block <NUM> can include both selecting and using bearer ID(s) <NUM> at the time of deallocation (blocks <NUM>, <NUM>). In some examples, block <NUM> does not include assigning the determined bearer ID(s) <NUM> to the bearer(s), but does include using the determined bearer ID(s) <NUM> in selecting the first bearer <NUM>.

In some examples, SPV <NUM> includes a priority flag. At block <NUM>, the control unit selects, as first bearer <NUM>, a bearer that is indicated by the SPV <NUM> as being low priority. In some examples, the control unit selects, as first bearer <NUM>, the bearer that is, out of all the bearer(s) indicated by the respective SPV(s) <NUM> as being low priority, the bearer that has the highest bearer ID <NUM>.

At <NUM>, the control unit determines that a first candidate bearer of the set of bearers has a first QV, a first RPV, and a first SPV. Block <NUM> can include selecting the first candidate bearer, or retrieving or inspecting values associated with an already-selected first candidate bearer. In some examples, the first candidate bearer can be selected randomly, or at least two bearers of the set <NUM> of bearers can be assigned as the first candidate bearer in turn.

At <NUM>, the control unit determines that a second candidate bearer of the set of bearers has the first QV, the first RPV, and a second SPV different from the first SPV. As in block <NUM>, block <NUM> can include selecting the second candidate bearer, e.g., as described above, or processing an existing second candidate bearer.

At <NUM>, the control unit selects, as the first bearer, one of the first candidate bearer and the second candidate bearer based at least in part on the first SPV, the second SPV, and a predetermined comparison function <NUM> ("CMP") (which can represent comparison function <NUM>). Function <NUM>, given two SPVs, determines which of the respective bearers is to be selected before the other. Block <NUM> permits, e.g., using a priority flag or other SPVs <NUM> to break ties of QCI+ARP, or other QVs <NUM> or RPVs <NUM>. For example, if only one of the first candidate bearer and the second candidate bearer has a priority flag indicating a high priority, the other of those bearers can be selected as the first bearer <NUM>. In some examples, function <NUM> can be any of the functions listed in Table <NUM>. Examples of processing at block <NUM> are described herein with reference to blocks <NUM>, <NUM>, <NUM>, <NUM>, or <NUM>. For example, as noted above, block <NUM> can include corresponding processing described with reference to <FIG> for both selecting bearer ID(s) <NUM> and using those ID(s) <NUM> in deallocation.

At <NUM>, the control unit reallocates the first bearer <NUM> at least partly by terminating session(s) being carried by the first bearer <NUM>. Examples are discussed herein, e.g., with reference to blocks <NUM> or <NUM>.

At <NUM>, the control unit determines that a second bearer <NUM> of the second access network <NUM> is unallocated. Examples are discussed herein, e.g., with reference to block <NUM>. Block <NUM> can be followed by block <NUM>.

At <NUM>, the control unit move session(s) being carried by the first bearer <NUM> to the second bearer <NUM>. Examples are discussed herein, e.g., with reference to block <NUM>.

Various examples include one or more of, including any combination of any number of, the following example features. Throughout these clauses, parenthetical remarks are for example and explanation, and are not limiting. Parenthetical remarks given in this Example Clauses section with respect to specific language apply to corresponding language throughout this section, unless otherwise indicated.

Many variations and modifications can be made to the above-described examples, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the claims. Moreover, this disclosure is inclusive of combinations of the aspects described herein. References to "a particular aspect" (or "embodiment" or "version") and the like refer to features that are present in at least one aspect of the invention. Separate references to "an aspect" (or "embodiment") or "particular aspects" or the like do not necessarily refer to the same aspect or aspects; however, such aspects are not mutually exclusive, unless so indicated or as are readily apparent to one of skill in the art. The use of singular or plural in referring to "method" or "methods" and the like is not limiting.

The methods, processes, or operations described above can be embodied in, and fully automated via, software code modules executed by one or more computers or processors. As used herein, the term "module" is intended to represent example divisions of the described operations (e.g., implemented in software or hardware) for purposes of discussion, and is not intended to represent any type of requirement or required method, manner or organization. Therefore, while various "modules" are discussed herein, their functionality and/or similar functionality can be arranged differently (e.g., combined into a smaller number of modules, broken into a larger number of modules, etc.). In some instances, the functionality and/or modules discussed herein may be implemented as part of a computer operating system (OS). In other instances, the functionality and/or modules may be implemented as part of a device driver, firmware, application, or other software subsystem.

Example computer-implemented operations described herein can additionally or alternatively be embodied in specialized computer hardware, e.g., FPGAs. For example, various aspects herein may take the form of an entirely hardware aspect, an entirely software aspect (including firmware, resident software, micro-code, etc.), or an aspect combining software and hardware aspects. These aspects can all generally be referred to herein as a "service," "circuit," "circuitry," "module," or "system.

The word "or" and the phrase "and/or" are used herein in an inclusive sense unless specifically stated otherwise. Accordingly, conjunctive language such as, but not limited to, at least one of the phrases "X, Y, or Z," "at least X, Y, or Z," "at least one of X, Y or Z," "one or more of X, Y, or Z," and/or any of those phrases with "and/or" substituted for "or," unless specifically stated otherwise, is to be understood as signifying that an item, term, etc. can be either X, or Y, or Z, or a combination of any elements thereof (e.g., a combination of XY, XZ, YZ, and/or XYZ). Any use herein of phrases such as "X, or Y, or both" or "X, or Y, or combinations thereof' is for clarity of explanation and does not imply that language such as "X or Y" excludes the possibility of both X and Y, unless such exclusion is expressly stated.

As used herein, language such as "one or more Xs" shall be considered synonymous with "at least one X" unless otherwise expressly specified. Any recitation of "one or more Xs" signifies that the described steps, operations, structures, or other features may, e.g., include, or be performed with respect to, exactly one X, or a plurality of Xs, in various examples, and that the described subject matter operates regardless of the number of Xs present, as long as that number is greater than or equal to one.

Conditional language such as, among others, "can," "could," "might" or "may," unless specifically stated otherwise, are understood within the context to present that certain examples include, while other examples do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that certain features, elements and/or steps are in any way required for one or more examples or that one or more examples necessarily include logic for deciding, with or without user input or prompting, whether certain features, elements and/or steps are included or are to be performed in any particular example.

Claim 1:
A telecommunication device (<NUM>, <NUM>, <NUM>, <NUM>), comprising:
a communications interface (<NUM>);
at least one processor (<NUM>); and
at least one computer-readable medium (<NUM>) storing instructions executable by the at least one processor to cause the at least one processor to perform operations comprising:
receiving (<NUM>) a request (<NUM>) to allocate a bearer for a terminal (<NUM>) to receive a network service via a first access network (<NUM>), wherein the network service is associated with a quality-of-service, QoS, value, QV, (<NUM>) and a retention-priority value, RPV (<NUM>);
determining (<NUM>) a bearer identifier, ID, (<NUM>) , for the network service based at least in part on the QV, the RPV, and a supplemental priority value, SPV (<NUM>); and
sending a reply (<NUM>) comprising the bearer identifier, ID, (<NUM>) via the communications interface (<NUM>);
wherein:
the SPV (<NUM>) is different from the QV (<NUM>),
the SPV (<NUM>) is different from the RPV (<NUM>), and
data indicating the QV (<NUM>) and the RPV (<NUM>) is included in the request (<NUM>).