WO2017193800A1 - 一种实现QoS管理的方法及装置 - Google Patents

一种实现QoS管理的方法及装置 Download PDF

Info

Publication number
WO2017193800A1
WO2017193800A1 PCT/CN2017/081489 CN2017081489W WO2017193800A1 WO 2017193800 A1 WO2017193800 A1 WO 2017193800A1 CN 2017081489 W CN2017081489 W CN 2017081489W WO 2017193800 A1 WO2017193800 A1 WO 2017193800A1
Authority
WO
WIPO (PCT)
Prior art keywords
keep
alive
pemp
response message
request
Prior art date
Application number
PCT/CN2017/081489
Other languages
English (en)
French (fr)
Inventor
陶峑郡
吴瑟
王卫斌
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2017193800A1 publication Critical patent/WO2017193800A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS

Definitions

  • the present application relates to, but is not limited to, a mobile broadband system technology, and more particularly to a method and apparatus for implementing Quality of Service (QoS) management.
  • QoS Quality of Service
  • the fifth generation (5G) mobile broadband system will become a wireless mobile communication system for the needs of the human information society.
  • the 5G mobile broadband system is a multi-service and multi-technology convergence network. Through the evolution and innovation of technology, it can meet the future wide range of data and connections.
  • the various businesses are constantly evolving to enhance the user experience. With the increase of the bandwidth and capabilities of wireless mobile communication systems, mobile Internet and IoT applications for individuals and industries are also developing rapidly, and the ecology of mobile communication related industries will undergo important changes. Wireless mobile communication technology and computer and information technology will be more closely and deeper cross-integration, integrated circuits, device technology, software technology, etc. will continue to develop rapidly to support the future development of 5G mobile broadband industry.
  • 5G networks need to provide users with an online experience at any time, and meet more high-value scenarios such as industrial control, emergency communications and so on.
  • it is required to further reduce the user plane delay and control plane delay, which is 5 to 10 times shorter than 4G, reaching the limit of human reaction such as 5ms (tactile response), and providing a true always-on experience.
  • some businesses that are related to people's lives and major property security require end-to-end reliability to be increased to 99.999% or even 100%.
  • the existing fourth-generation (4G) all-IP packet core network EPC, Evolved Packet Core), Evolved Packet System (EPS) quality of service (QoS, Quality of Service) management architecture shown in Figure 1. .
  • EPC Evolved Packet Core
  • EPS Evolved Packet System
  • QoS Quality of Service
  • the existing QoS management is mainly controlled by the terminal, the base station, and the packet gateway.
  • the QoS parameters subscribed by the user are transmitted to the terminal, the base station, and the packet through the control plane signaling by the control network element, such as the Mobility Management Entity (MME).
  • MME Mobility Management Entity
  • the terminal, the base station, and the packet gateway forwarding plane device need to establish a bearer connection and save the state information of the bearer, which undoubtedly increases the complexity of the forwarding device and may eventually affect the forwarding performance of the forwarding device.
  • the present application provides a method and apparatus for implementing QoS management, which can reduce the complexity of the forwarding device and improve the forwarding performance of the forwarding device.
  • the application provides a method for implementing QoS management, including:
  • the Policy Execution Monitoring Point that receives the keep-alive request performs the keep-alive processing according to the preset keep-alive processing policy, and forwards the keep-alive request to the next-hop PEMP according to the service chain identifier carried in the keep-alive request until the last hop.
  • PEMP Policy Execution Monitoring Point
  • the last-hop PEMP After receiving the keep-alive request, the last-hop PEMP performs corresponding processing according to the preset keep-alive processing policy.
  • the PEMP that receives the keep-alive request is the first PEMP, and the PEMP that receives the keep-alive request performs the keep-alive processing according to the preset keep-alive processing policy, which may include:
  • the first PEMP receives the keep-alive request from the network control network element, performs the keep-alive processing according to the keep-alive processing policy, and forwards the keep-alive request to the next-hop PEMP according to the service chain identifier carried in the keep-alive request.
  • the keep-alive processing policy may include: replying to the network control network element that initiates the keep-alive request, indicating that the keep-alive request is received;
  • the keepalive request is forwarded to the next hop PEMP.
  • the method may further include:
  • the PEMP receiving the keep-alive request returns a keep-alive failure notification to the network control network element, and ends.
  • the method may further include: the PEMP receiving the keep-alive request sensing the survival of the self node.
  • performing the keep-alive processing corresponding to the preset keep-alive processing policy may include:
  • the present application further provides an apparatus for implementing QoS management, including: a receiving module and a processing module; wherein, the receiving module is configured to receive a keep-alive request; and the processing module is configured to perform keep-alive processing according to a preset keep-alive processing policy. And forwarding the keep-alive request to the next hop PEMP according to the service chain identifier carried in the keep-alive request.
  • the keep-alive processing policy may include:
  • the timer is set to wait for the next hop PEMP, that is, the forward PEMP replies with a keep-alive temporary response message indicating that the link between the current PEMP and its forward PEMP is unblocked;
  • the keepalive request is forwarded directly to the next hop PEMP.
  • the processing module may be configured to: when the PEMP to which it belongs is not the last hop PEMP,
  • the keep-alive processing policy is to set a timer to wait for the next-hop PEMP to reply to the keep-alive temporary response message
  • the processing module may be further configured to: when the timer expires and still not receive the keep-alive temporary response message returned by the next-hop PEMP, return a keep-alive failure notification to the network control network element that initiates the keep-alive request.
  • the application also provides a machine readable medium storing computer executable instructions that, when executed by a processor, implement the method of implementing QoS management described above.
  • the technical solution provided by the application includes: receiving, by the first PEMP, a keep-alive request from the network control network element, performing a keep-alive process according to a preset keep-alive processing policy, and performing a service chain identifier carried in the keep-alive request to the next one.
  • the PEMP forwards the keep-alive request; the PEMP that receives the keep-alive request performs the keep-alive processing according to the preset keep-alive processing policy, and forwards the keep-alive request to the next-hop PEMP according to the service chain identifier carried in the keep-alive request until the last hop PEMP; the last hop PEMP receives the keep-alive request and performs the keep-alive processing corresponding to the pre-set policy.
  • the method for implementing keep-alive in the QoS management provided by the present application does not require the uplink and downlink routes to be symmetric, and is applicable to the architecture for implementing QoS management as shown in FIG. 2, which provides a prerequisite for the implementation of keep-alive, and reduces the complexity of the forwarding device. And improve the forwarding performance of the forwarding device.
  • FIG. 1 is a schematic diagram of a QoS management architecture of an EPS in related art
  • FIG. 2 is a schematic structural diagram of implementing QoS management in the present application.
  • FIG. 3 is a flowchart of an embodiment of a method for implementing QoS management according to the present application
  • FIG. 4 is a schematic flowchart of a first embodiment of a method for implementing QoS management according to the present application
  • FIG. 5 is a schematic flowchart diagram of a second embodiment of a method for implementing QoS management according to the present application
  • FIG. 6 is a schematic flowchart diagram of a third embodiment of a method for implementing QoS management according to the present application.
  • FIG. 7 is a schematic structural diagram of a device for implementing QoS management according to the present application.
  • FIG. 2 is a schematic diagram of an architecture for implementing QoS management in the present application, where at least The system includes: an access network element, a policy enforcement monitoring point (PEMP, a Policy Enforcement & Monitor Point), a network control network element (Network Controller), and a marginal gateway;
  • PEMP policy enforcement monitoring point
  • Network Controller Network Controller
  • the access network element includes an access control network element and a forwarding network element.
  • the access control network element is configured to insert user QoS information into the packet and select a QoS path for the packet according to the QoS information subscribed by the user and the reserved bandwidth of the service when the user initiates the uplink service.
  • the NE is configured to forward the packet.
  • the PEMP is configured to detect whether the path meets the QoS requirement according to the QoS information carried in the packet. When the path quality is reduced and the QoS requirement of the packet cannot be met, the PEMP is notified to the network control network element.
  • the network control network element is configured to process received alarms, such as adjusting the network.
  • the marginal gateway is configured to insert user QoS information into the packet and select a QoS path for the packet according to the QoS information subscribed by the user and the reserved bandwidth of the service when the downlink data packet is delivered.
  • the method for implementing keep-alive substantially includes: in the downlink direction, the network control network element sends a keep-alive request to the first PEMP, in the keep-alive request
  • the service carries the service chain identifier. If the first PEMP is alive, the packet is forwarded according to the service chain identifier to the next hop, that is, the second PEMP, and the timer is set to wait for the next hop PEMP to reply to the keep-alive response until the packet is forwarded to the packet.
  • the last hop PEMP returns the keep-alive response message to the backward PEMP in stages according to the downlink path.
  • the routing mechanism between the PEMPs adopts a service link mode, which is an asymmetric route, that is, a one-way routing mode, if the implementation is well known to those skilled in the art.
  • the method is applied to the architecture shown in Figure 2.
  • the PEMP cannot return the keep-alive response message to the first PEMP according to the service chain identifier in the packet, which means that the keep-alive implementation fails.
  • the process of maintaining the keepalive includes: the PEMP receiving the keep-alive request performs the keep-alive processing according to the preset keep-alive processing policy, and carries the data according to the keep-alive request.
  • the service chain identifies the next-hop PEMP forwarding keep-alive request; until the last-hop PEMP receives the keep-alive request, the keep-alive processing corresponding to the preset keep-alive processing policy is performed.
  • FIG. 3 is a flowchart of an embodiment of a method for implementing QoS management according to the present application. As shown in FIG. 3, the method includes:
  • Step 300 The first PEMP receives the keep-alive request from the network control network element, performs the keep-alive processing according to the preset keep-alive processing policy, and forwards the keep-alive PEMP according to the service chain identifier carried in the keep-alive request. request.
  • the first PEMP senses that its own node is alive, it performs subsequent processing, otherwise it exits the process.
  • the keep-alive processing policy in this step may include: replying to the network control network element a notification indicating that the keep-alive request is received; or setting a timer to wait for the next-hop PEMP, that is, the forward PEMP reply is used to indicate the current PEMP and its forward direction.
  • the link between PEMPs is a smooth keep-alive temporary response message; or, the keep-alive request is directly forwarded to the next-hop PEMP.
  • the method in this embodiment may further include :
  • the first PEMP If the first PEMP considers that the link between itself and the next hop PEMP may be interrupted, the first PEMP directly returns a keep-alive failure notification to the network control network element, and ends the process.
  • Step 301 The PEMP that receives the keep-alive request performs the keep-alive processing according to the preset keep-alive processing policy, and forwards the keep-alive request to the next-hop PEMP according to the service chain identifier carried in the keep-alive request until the last-hop PEMP.
  • Step 302 The last hop PEMP receives the keep-alive request, and performs the keep-alive according to the preset Process the corresponding keep-alive processing.
  • the corresponding keep-alive processing according to the preset keep-alive processing policy in this step includes:
  • the keep-alive response message is sent to the network control network element, so that the network control network element confirms that the service chain link is clear according to the keep-alive response message.
  • the method for implementing keep-alive in the QoS management provided by the present application does not require the uplink and downlink routes to be symmetric, and is applicable to the architecture for implementing QoS management as shown in FIG. 2, which provides a prerequisite for the implementation of keep-alive, and reduces the complexity of the forwarding device. And improve the forwarding performance of the forwarding device.
  • the keep-alive processing policy is: replying to the network control network element to indicate that the keep-alive request is received. Notice.
  • the implementation process of this embodiment includes:
  • Step 400 The network control network element sends a keep-alive request to the first PEMP, where the keep-alive request carries the service chain identifier.
  • Step 401 If the first PEMP is alive, forwarding the keep-alive request to the next hop according to the service chain identifier, such as the second PEMP in FIG. 4, and the first PEMP replies to the network control network element to indicate that the keep-alive request is received. .
  • the notification indicating that the keep-alive request is received may be a keep-alive response message or a new notification message set in advance.
  • the emphasis here is to notify the network control network element after the PEMP receives the keep-alive request, as for the notification.
  • the manner is not intended to limit the scope of protection of the present application.
  • Step 403 to step 404 The processing of the PEMP (except the last hop PEMP) that receives the keep-alive request is completely consistent with the processing of the first PEMP receiving the keep-alive request, and details are not described herein again.
  • Step 405 to step 406 The last hop PEMP receives the keep-alive request, and returns a keep-alive response message to the network control network element, so that the network control network element confirms that the service chain link is clear according to the keep-alive response message.
  • FIG. 5 is a schematic flowchart of a second embodiment of implementing QoS management according to the present application.
  • the keep-alive processing policy is: setting a timer to wait for a next-hop PEMP, that is, a forward PEMP reply.
  • This embodiment is described by using a four-level PEMP as an example.
  • the implementation process of this embodiment includes:
  • Step 500 The network control network element sends a keep-alive request to the first PEMP, where the keep-alive request carries the service chain identifier.
  • Step 501 to step 502 If the first PEMP perceives itself to be alive, the forwarding of the keepalive request to the next hop PEMP, that is, the second PEMP, according to the service chain identifier, and the first PEMP sets a timer according to the preset keep-alive processing policy. It is used to wait for its forward node, that is, the second PEMP, to return a keep-alive temporary response message.
  • the keep-alive temporary response message is used to indicate that the link between the first PEMP and the second PEMP is unblocked.
  • the first PEMP If the first PEMP considers that the link between the first PEMP and the second PEMP may be interrupted, the first PEMP directly returns the keep-alive to the network control network element. Failure notification and end this process.
  • Step 503 to step 504 The second PEMP receives the keep-alive request, and if the sensing itself is alive, returns a keep-alive temporary response message to the first node, that is, the first PEMP, and forwards the keep-alive request to the third PEMP.
  • a timer is set to wait for the forward node, that is, the third PEMP, to return a keep-alive temporary response message.
  • the second PEMP considers that the link between itself and the third PEMP may be interrupted, and directly returns the protection to the network control network element. Live failure notification and end this process.
  • Step 505 to step 507 The last hop PEMP receives the keep-alive request and detects that it is alive. Then, it returns a keep-alive temporary response message to the backward node, and returns a keep-alive response message to the network control network element.
  • the last-hop PEMP returns to the network control in addition to the keep-alive temporary response message indicating that the link between itself and its backward node is unblocked according to the preset keep-alive processing policy.
  • the network element returns a keep-alive response message, so that the network control network element confirms that the service chain link is clear according to the keep-alive response message.
  • FIG. 6 is a schematic flowchart of a third embodiment of implementing QoS management according to the present application; as shown in FIG. 6, in the third embodiment, the keep-alive processing policy is: directly forwarding the keep-alive request to the next-hop PEMP.
  • the implementation process of this embodiment includes:
  • Step 600 The network control network element sends a keep-alive request to the first PEMP, where the keep-alive request carries the service chain identifier.
  • Step 601 If the first PEMP senses its own survival, directly send the received keep-alive request to its forward node, that is, the second PEMP.
  • Step 602 The processing of the received keep-alive request by the second PEMP is completely consistent with step 601, and details are not described herein again.
  • Step 603 After receiving the keep-alive request, the last-hop PEMP sends a keep-alive response message to the network control network element, so that the network control network element confirms that the service chain link is clear according to the keep-alive response message.
  • Embodiments of the present invention also provide a machine readable medium storing computer executable instructions that, when executed by a processor, implement any of the methods described above for implementing QoS management.
  • FIG. 7 is a schematic structural diagram of a device for implementing QoS management according to the present application. As shown in FIG. 7, the method includes at least a receiving module 701, and a processing module 702.
  • the receiving module 701 is configured to receive a keep-alive request
  • the processing module 702 is configured to perform keep-alive processing according to the preset keep-alive processing policy, and forward the keep-alive request to the next-hop PEMP according to the service chain identifier carried in the keep-alive request.
  • the keep-alive processing policy may include: replying to the network control network element a notification indicating that the keep-alive request is received; or setting a timer to wait for the next-hop PEMP, that is, the forward PEMP reply is used to indicate the current PEMP and its forward PEMP.
  • the inter-link is an uninterrupted keep-alive reply message; or, the keep-alive request is forwarded directly to the next-hop PEMP.
  • the processing module 702 can be configured to:
  • the pre-set keep-alive processing is performed.
  • the policy returns a notification indicating that the keep-alive request is received to the network control network element; or, the timer is set to wait for the next-hop PEMP, that is, the forward PEMP reply is used to indicate that the link between the current PEMP and its forward PEMP is unblocked. Keep a temporary reply message; or directly forward the keep-alive request to the next-hop PEMP;
  • the PEMP to which it belongs is the last-hop PEMP, the following corresponding processing is performed according to the preset keep-alive processing policy:
  • the keep-alive response message is sent to the network control network element, so that the network control network element confirms that the service chain link is clear according to the keep-alive response message.
  • the processing module 702 may further be configured to:
  • the link between the PEMP and the next hop PEMP may be interrupted, and the keepalive failure notification is directly returned to the network control network element.
  • Such software may be distributed on a machine-readable medium, such as a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transitory media).
  • a machine-readable medium such as a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transitory media).
  • computer storage medium includes the volatility embodied in any method or technique for storing information, such as computer readable instructions, data structures, program modules, or other data. And non-volatile, removable and non-removable media.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridge, magnetic tape, magnetic disk storage or other magnetic storage device, or may Any other medium used to store the desired information and that can be accessed by the computer.
  • communication media typically includes computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and can include any information delivery media. .
  • the embodiment of the present invention provides a method and a device for implementing QoS management.
  • the method for implementing keep-alive does not require the uplink and downlink routes to be symmetric, which provides a prerequisite for the implementation of keep-alive, reduces the complexity of the forwarding device, and improves forwarding. Forwarding performance of the device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本文公开了一种实现QoS管理的方法及装置；上述实现QoS管理的方法，包括：第一PEMP收到来自网络控制网元的保活请求，按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求；收到保活请求的PEMP按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至最后一跳PEMP；最后一跳PEMP在收到保活请求后，进行与按照预先设置的保活处理策略相应的保活处理。

Description

一种实现QoS管理的方法及装置 技术领域
本申请涉及但不限于移动宽带系统技术，尤指一种实现服务质量(QoS，Quality of Service)管理的方法及装置。
背景技术
移动通信的发展给人们生活方式、工作方式以及社会的政治、经济等各方面都带来了巨大的影响。随着人类社会进入高效的信息化时代，各个方面业务应用需求呈现爆发式增长，给未来无线移动带宽系统在频率、技术以及运营等各方面都带来了巨大的挑战。
第五代(5G)移动宽带系统将成为面向人类信息社会需求的无线移动通信系统，5G移动宽带系统是一个多业务多技术融合的网络，通过技术的演进和创新，满足未来广泛的数据、连接的各种业务不断发展的需要，以提升用户体验。随着无线移动通信系统带宽和能力的提升，面向个人和行业的移动互联网和物联网应用也在快速发展，移动通信相关产业生态将发生重要变化。无线移动通信技术与计算机及信息技术会更加紧密和更深层次的交叉融合，集成电路、器件工艺、软件技术等也将持续快速发展，以支撑未来5G移动宽带产业发展。
根据社会职责和功能、终端用户、业务应用和网络运营等对未来5G的愿景分析，从技术的角度总结5G的关键能力需求如下：
一方面，基于近年来移动通信网络数据流量增长趋势，业界预测到2020年，全球总移动数据流量将达到2010年总移动数据流量的1000倍。这要求单位面积的吞吐量能力，特别是忙时吞吐量能力同样有1000倍的提升，需要达到100Gbps/km2以上。
另一方面，未来5G网络用户范畴极大扩展，随着物联网的快速发展，业界预计到2020年连接的器件数目将达到500至1000亿。这就要求单位覆盖面积内支持的器件数目将极大增长，在一些场景下单位面积内通过5G移 动网络连接的器件数目达到100万/km2，相对4G将增长100倍。
另外，5G网络需要为用户提供随时在线的体验，并满足诸如工业控制、紧急通信等更多高价值场景需求。这样，一方面要求进一步降低用户面时延和控制面时延，相对4G缩短5至10倍，达到人类反应的极限如5ms(触觉反应)，并提供真正的永远在线体验。另一方面，一些关系人的生命、重大财产安全的业务，要求端到端可靠性提升到99.999％甚至100％。
现有的第四代(4G)全IP的分组核心网(EPC，Evolved Packet Core)，演进分组系统(EPS，Evolved Packet System)的服务质量(QoS，Quality of Service)管理架构如图1所示。
现有的QoS管理主要由终端、基站以及分组网关等节点进行控制，用户签约的QoS参数由控制网元如移动管理实体(MME，Mobility Management Entity)通过控制面信令传递到终端、基站及分组网关等节点，这种处理机制主要存在以下问题：
终端和服务器之间，没有真正实现端到端的QoS保证服务链接，如图1中所示，基站和分组网关之间的传输网，以及分组网关与外部服务器之间没有实现完善的QoS保障。而为了实现QoS管理，终端、基站和分组网关转发面设备需要建立承载连接，并保存承载的状态信息，这样无疑增加了转发设备的复杂度，并最终可能影响到转发设备的转发性能。
发明概述
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
本申请提供一种实现QoS管理的方法及装置，能够降低转发设备的复杂度，并提高转发设备的转发性能。
本申请提供了一种实现QoS管理的方法，包括：
收到保活请求的策略执行监控点(PEMP)按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至最后一跳PEMP；
由最后一跳PEMP在收到保活请求后，按照预先设置的保活处理策略进行相应的处理。
在示例性实施方式中，所述收到保活请求的PEMP为第一PEMP；所述收到保活请求的PEMP按照预先设置的保活处理策略进行保活处理可以包括：
第一PEMP收到来自网络控制网元的保活请求，按照所述保活处理策略进行保活处理，并根据所述保活请求中携带的业务链标识向下一跳PEMP转发保活请求。
在示例性实施方式中，所述保活处理策略可以包括：向发起所述保活请求的网络控制网元回复表示收到保活请求的通知；
或者，设置定时器等待下一跳PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；
或者，将所述保活请求转发给下一跳PEMP。
在示例性实施方式中，所述保活处理策略为设置定时器等待下一跳PEMP回复所述保活临时应答消息时，上述方法还可以包括：
如果所述定时器超时仍未收到下一跳PEMP返回的保活临时应答消息，所述收到保活请求的PEMP向所述网络控制网元返回保活失败通知，并结束。
在示例性实施方式中，所述按照预先设置的保活处理策略进行保活处理之前，上述方法还可以包括：所述收到保活请求的PEMP感知出自身节点存活。
在示例性实施方式中，所述最后一跳PEMP在收到保活请求后，进行与按照预先设置的保活处理策略相应的保活处理可以包括：
如果所述最后一跳PEMP感知自身节点存活，
向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；或者，
向所述最后一跳PEMP的后向节点返回保活临时应答消息，以便确定所述最后一跳PEMP自身与其后向PEMP之间的链路是畅通；以及，向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；或者，
向所述网络控制网元发送保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通。
本申请还提供了一种实现QoS管理的装置，包括：接收模块、处理模块；其中，接收模块，配置为接收保活请求；处理模块，配置为按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求。
在示例性实施方式中，所述保活处理策略可以包括：
向发起所述保活请求的网络控制网元回复表示收到保活请求的通知；
或者，设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；
或者，直接将保活请求转发给下一跳PEMP。
在示例性实施方式中，所述处理模块可以配置为：当自身所属的PEMP不是最后一跳PEMP时，
按照所述保活处理策略，向所述网络控制网元回复表示收到保活请求的通知；或者，设置所述定时器等待下一跳PEMP即前向PEMP回复所述保活临时应答消息；或者，将所述接收到的保活请求转发给下一跳PEMP；
当自身所属的PEMP是最后一跳PEMP时，按照所述保活处理策略进行以下的相应处理：
向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；
或者，向自身所属的PEMP的后向节点返回保活临时应答消息，以便确定自身所属的PEMP与其后向PEMP之间的链路是畅通，以及，向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；
或者，向所述网络控制网元发送保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通。
在示例性实施方式中，当所述保活处理策略为设置定时器等待下一跳PEMP回复保活临时应答消息时，
所述处理模块还可以配置为：当定时器超时仍未收到下一跳PEMP返回的保活临时应答消息时，向发起所述保活请求的网络控制网元返回保活失败通知。
本申请还提供一种机器可读介质，存储有计算机可执行指令，当所述计算机可执行指令被处理器执行时实现上述的实现QoS管理的方法。
本申请提供的技术方案包括：第一PEMP收到来自网络控制网元的保活请求，按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求；收到保活请求的PEMP按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至最后一跳PEMP；最后一跳PEMP收到保活请求，进行与按照预先设置的保活处理策略相应的保活处理。本申请提供的QoS管理中实现保活的方法并不要求上行下行路由对称，适用于图2所示的实现QoS管理的架构，为保活的实现提供了前提，同时降低了转发设备的复杂度，并提高了转发设备的转发性能。
本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图概述
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为相关技术中EPS的QoS管理架构示意图；
图2为本申请中实现QoS管理的架构示意图；
图3为本申请的实现QoS管理的方法的实施例的流程图；
图4为本申请的实现QoS管理的方法的第一实施例的流程示意图；
图5为本申请的实现QoS管理的方法的第二实施例的流程示意图；
图6为本申请的实现QoS管理的方法的第三实施例的流程示意图；
图7为本申请的实现QoS管理的装置的组成结构示意图。
详述
下文中将结合附图对本申请的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
为了降低转发设备的复杂度，并提高转发设备的转发性能，本申请提出了一种实现QoS管理的架构，如图2所示，图2为本申请中实现QoS管理的架构的示意图，其中至少包括：接入网元、策略执行监控点(PEMP，Policy Enforcement&Monitor Point)、网络控制网元(Network Controller)，以及边际网关；其中，
接入网元，包括接入控制网元和转发网元。其中，接入控制网元，主要配置为在用户发起上行业务时，根据用户签约的QoS信息和访问的业务预留带宽，在报文中插入用户QoS信息并为该报文选择QoS路径；转发网元，配置为转发该报文；
PEMP，主要配置为根据报文中携带的QoS信息，检测路径是否满足QoS要求，当路径质量降低不能满足该报文的QoS要求时，向网络控制网元告警；
网络控制网元，配置为对收到的告警进行处理，如对网络进行调整等。
边际网关，主要配置为在传递下行数据报文时，根据用户签约的QoS信息和访问的业务预留带宽，在报文中插入用户QoS信息并为该报文选择QoS路径。
基于图2所示的本申请提出的实现QoS管理的架构，按照相关技术方案，实现保活的方法大致会包括：下行方向，网络控制网元向第一PEMP发送保活请求，在保活请求中携带有业务链标识；如果第一PEMP存活，则会根据业务链标识转发报文至下一跳即第二PEMP，并设置定时器等待下一跳PEMP回复保活应答，直到报文转发至最后一跳PEMP，按照下行路径原路向后向节点PEMP逐级返回保活应答消息。
从本领域技术人员公知的实现保活的方法来看，报文转发的下行路径和上行应答路径必须是同一条路径，即是对称路径，否则，保活应答消息是无 法正确返回的。而图2所示的实现QoS管理的架构中，PEMP间的路由机制采用业务链路由方式，是一种非对称路由即单向路由方式，如果还直接将本领域技术人员公知的实现保活的方法应用在图2所示的架构中，PEMP根据报文中业务链标识是无法将保活应答消息返回到第一PEMP的，也就是说会导致保活实现的失败。
本申请为了适应图2所示的实现QoS管理的架构，对保活的处理包括：收到保活请求的PEMP按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求；直至最后一跳PEMP收到保活请求，进行与按照预先设置的保活处理策略相应的保活处理。图3为本申请的实现QoS管理的方法的实施例的流程图，如图3所示，包括：
步骤300：第一PEMP收到来自网络控制网元的保活请求，按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求。
如果第一PEMP感知自身节点存活，则进行后续处理，否则退出本流程。
本步骤中的保活处理策略可以包括：向网络控制网元回复表示收到保活请求的通知；或者，设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；或者，直接将保活请求转发给下一跳PEMP。
当保活处理策略为设置定时器等待下一跳PEMP回复保活临时应答消息时，如果定时器超时仍未收到下一跳PEMP返回的保活临时应答消息，本实施例的方法还可以包括：
第一PEMP认为自身与下一跳PEMP之间的链路可能中断，则直接向网络控制网元返回保活失败通知，并结束本流程。
步骤301：收到保活请求的PEMP按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至最后一跳PEMP。
本步骤的实现与步骤300中的完全一致，这里不再赘述。
步骤302：最后一跳PEMP收到保活请求，进行与按照预先设置的保活 处理策略相应的保活处理。
如果最后一跳PEMP感知自身节点存活，本步骤中的按照预先设置的保活处理策略相应的保活处理包括：
向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通；或者，
向后向节点返回保活临时应答消息，以便确定最后一跳PEMP自身与后向PEMP之间的链路是畅通的；以及，向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通；或者，
向网络控制网元发送保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通。
本申请提供的QoS管理中实现保活的方法并不要求上行下行路由对称，适用于图2所示的实现QoS管理的架构，为保活的实现提供了前提，同时降低了转发设备的复杂度，并提高了转发设备的转发性能。
下面结合实施例对本申请基于图2所示的架构提出的实现保活的方法进行详细描述。
图4为本申请的实现QoS管理的第一实施例的流程示意图，如图4所示，第一实施例中，假设保活处理策略为：向网络控制网元回复表示收到保活请求的通知。本实施例的实现过程包括：
步骤400：网络控制网元向第一PEMP发送保活请求，在保活请求中携带有业务链标识。
步骤401：如果第一PEMP存活，根据业务链标识转发保活请求至下一跳，如图4中的第二PEMP，并且，第一PEMP向网络控制网元回复表示收到保活请求的通知。
本步骤中，表示收到保活请求的通知可以是保活应答消息，或者是预先设置的新的通知消息，这里强调的是在PEMP收到保活请求后通知网络控制网元，至于通知的方式并不用于限定本申请的保护范围。
步骤403～步骤404：后续收到保活请求的PEMP(除最后一跳PEMP外)的处理与第一PEMP收到保活请求的处理是完全一致的，这里不再赘述。
步骤405～步骤406：最后一跳PEMP收到保活请求，向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通。
图5为本申请的实现QoS管理的第二实施例的流程示意图，如图5所示，第二实施例中，假设保活处理策略为：设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息。本实施例中以包括四级PEMP为例进行描述，本实施例的实现过程包括：
步骤500：网络控制网元向第一PEMP发送保活请求，在保活请求中携带有业务链标识。
步骤501～步骤502：如果第一PEMP感知自身存活，根据业务链标识转发保活请求至下一跳PEMP即第二PEMP，并且，第一PEMP按照预先设置的保活处理策略，设置定时器，用于等待其前向节点即第二PEMP返回保活临时应答消息。
其中，保活临时应答消息用于表示第一PEMP和第二PEMP之间的链路是畅通的。
其中，如果定时器超时仍未收到第二PEMP返回的保活临时应答消息，那么，第一PEMP认为自身与第二PEMP之间的链路可能中断，则直接向网络控制网元返回保活失败通知，并结束本流程。
步骤503～步骤504：第二PEMP收到保活请求，如果感知自身存活，则向后向节点即第一PEMP返回保活临时应答消息，向前向节点即第三PEMP转发保活请求，并按照预先设置的保活处理策略，设置定时器，用于等待其前向节点即第三PEMP返回保活临时应答消息。
本步骤的实现与步骤501～步骤502完全一致，这里不再赘述。
同样地，如果定时器超时仍未收到第三PEMP返回的保活临时应答消息，那么，第二PEMP认为自身与第三PEMP之间的链路可能中断，则直接向网络控制网元返回保活失败通知，并结束本流程。
步骤505～步骤507：最后一跳PEMP收到保活请求，感知自身存活，则向后向节点返回保活临时应答消息，并向网络控制网元返回保活应答消息。
本步骤中，最后一跳PEMP除了按照预先设置的保活处理策略向其后向节点返回表示自身和与其后向节点之间的链路是畅通的保活临时应答消息外，还会向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通。
图6为本申请的实现QoS管理的第三实施例的流程示意图；如图6所示，第三实施例中，假设保活处理策略为：直接将保活请求转发给下一跳PEMP。本实施例的实现过程包括：
步骤600：网络控制网元向第一PEMP发送保活请求，在保活请求中携带有业务链标识。
步骤601：如果第一PEMP感知自身存活，直接将收到的保活请求发送给其前向节点即第二PEMP。
步骤602：第二PEMP对收到的保活请求的处理与步骤601完全一致，这里不再赘述。
步骤603：最后一跳PEMP收到保活请求后，向网络控制网元发送保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通。
本发明实施例还提供了一种机器可读介质，存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现上述任一实现QoS管理的方法。
图7为本申请的实现QoS管理的装置的组成结构示意图，如图7所示，至少包括：接收模块701，处理模块702；其中，
接收模块701，配置为接收保活请求；
处理模块702，配置为按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求。
其中，保活处理策略可以包括：向网络控制网元回复表示收到保活请求的通知；或者，设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；或者，直接将保活请求转发给下一跳PEMP。
其中，处理模块702可以配置为：
当自身所属的PEMP不是最后一跳PEMP时，按照预先设置的保活处理 策略，向网络控制网元回复表示收到保活请求的通知；或者，设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；或者，直接将保活请求转发给下一跳PEMP；
当自身所属的PEMP是最后一跳PEMP时，按照预先设置的保活处理策略进行以下相应处理：
向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通；或者，
向后向节点返回保活临时应答消息，以便确定最后一跳PEMP自身与后向PEMP之间的链路是畅通；以及，向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通；或者，
向网络控制网元发送保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通。
在示例性实施方式中，当预先设置的保活处理策略为设置定时器等待下一跳PEMP回复保活临时应答消息时，处理模块702还可以配置为：
当定时器超时仍未收到下一跳PEMP返回的保活临时应答消息时，认为自身所属PEMP与下一跳PEMP之间的链路可能中断，直接向网络控制网元返回保活失败通知。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在机器可读介质(比如，计算机可读介质)上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性 和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
以上所述，仅为本申请的较佳实例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
工业实用性
本申请实施例提供一种实现QoS管理的方法及装置，实现保活的方法并不要求上行下行路由对称，为保活的实现提供了前提，同时降低了转发设备的复杂度，并提高了转发设备的转发性能。

Claims (11)

  1. 一种实现服务质量QoS管理的方法，包括：
    收到保活请求的策略执行监控点PEMP按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至最后一跳PEMP；由最后一跳PEMP在收到保活请求后，按照预先设置的保活处理策略进行相应的处理。
  2. 根据权利要求1所述的方法，其中，所述收到保活请求的PEMP为第一PEMP；所述收到保活请求的PEMP按照预先设置的保活处理策略进行保活处理包括：
    第一PEMP收到来自网络控制网元的保活请求，按照所述保活处理策略进行保活处理，并根据所述保活请求中携带的业务链标识向下一跳PEMP转发保活请求。
  3. 根据权利要求1或2所述的方法，其中，所述保活处理策略包括：向发起所述保活请求的网络控制网元回复表示收到保活请求的通知；
    或者，设置定时器等待下一跳PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；
    或者，将所述保活请求转发给下一跳PEMP。
  4. 根据权利要求1或2所述的方法，所述保活处理策略为设置定时器等待下一跳PEMP回复保活临时应答消息时，所述方法还包括：
    如果所述定时器超时仍未收到下一跳PEMP返回的保活临时应答消息，所述收到保活请求的PEMP向所述网络控制网元返回保活失败通知，并结束。
  5. 根据权利要求1或2所述的方法，所述按照预先设置的保活处理策略进行保活处理之前，所述方法还包括：所述收到保活请求的PEMP感知出自身节点存活。
  6. 根据权利要求3所述的方法，其中，所述最后一跳PEMP在收到保活请求后，进行与按照预先设置的保活处理策略相应的保活处理包括：
    如果所述最后一跳PEMP感知自身节点存活，
    向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；或者，
    向所述最后一跳PEMP的后向节点返回保活临时应答消息，以便确定所述最后一跳PEMP自身与其后向PEMP之间的链路是畅通；以及，向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；或者，
    向所述网络控制网元发送保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通。
  7. 一种实现服务质量QoS管理的装置，包括：接收模块、处理模块；其中，
    接收模块，配置为接收保活请求；
    处理模块，配置为按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳策略执行监控点PEMP转发保活请求。
  8. 根据权利要求7所述的装置，其中，所述保活处理策略包括：
    向发起所述保活请求的网络控制网元回复表示收到保活请求的通知；
    或者，设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；
    或者，直接将保活请求转发给下一跳PEMP。
  9. 根据权利要求8所述的装置，其中，所述处理模块配置为：
    当自身所属的PEMP不是最后一跳PEMP时，
    按照所述保活处理策略，向所述网络控制网元回复表示收到保活请求的通知；或者，设置所述定时器等待下一跳PEMP即前向PEMP回复所述保活临时应答消息；或者，将所述接收到的保活请求转发给下一跳PEMP；
    当自身所属的PEMP是最后一跳PEMP时，按照所述保活处理策略进行以下的相应处理：
    向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；
    或者，向自身所属的PEMP的后向节点返回保活临时应答消息，以便确定自身所属的PEMP与其后向PEMP之间的链路是畅通，以及，向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；
    或者，向所述网络控制网元发送保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通。
  10. 根据权利要求7所述的装置，其中，当所述保活处理策略为设置定时器等待下一跳PEMP回复保活临时应答消息时，
    所述处理模块还配置为：当定时器超时仍未收到下一跳PEMP返回的保活临时应答消息时，向发起所述保活请求的网络控制网元返回保活失败通知。
  11. 一种机器可读介质，存储有计算机可执行指令，当所述计算机可执行指令被处理器执行时实现权利要求1至6任一项所述的实现服务质量QoS管理的方法。
PCT/CN2017/081489 2016-05-09 2017-04-21 一种实现QoS管理的方法及装置 WO2017193800A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610301588.3 2016-05-09
CN201610301588.3A CN107360203A (zh) 2016-05-09 2016-05-09 一种实现QoS管理的方法及装置

Publications (1)

Publication Number Publication Date
WO2017193800A1 true WO2017193800A1 (zh) 2017-11-16

Family

ID=60266310

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/081489 WO2017193800A1 (zh) 2016-05-09 2017-04-21 一种实现QoS管理的方法及装置

Country Status (2)

Country Link
CN (1) CN107360203A (zh)
WO (1) WO2017193800A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101616094A (zh) * 2009-08-10 2009-12-30 杭州华三通信技术有限公司 报文转发路径的获取方法和设备
CN101826989A (zh) * 2009-03-02 2010-09-08 华为技术有限公司 一种故障处理方法和装置
CN104618232A (zh) * 2015-01-28 2015-05-13 杭州华三通信技术有限公司 广域网业务链路选择方法及装置
WO2015188682A1 (zh) * 2014-06-10 2015-12-17 华为技术有限公司 业务链的处理方法、装置与系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101826989A (zh) * 2009-03-02 2010-09-08 华为技术有限公司 一种故障处理方法和装置
CN101616094A (zh) * 2009-08-10 2009-12-30 杭州华三通信技术有限公司 报文转发路径的获取方法和设备
WO2015188682A1 (zh) * 2014-06-10 2015-12-17 华为技术有限公司 业务链的处理方法、装置与系统
CN104618232A (zh) * 2015-01-28 2015-05-13 杭州华三通信技术有限公司 广域网业务链路选择方法及装置

Also Published As

Publication number Publication date
CN107360203A (zh) 2017-11-17

Similar Documents

Publication Publication Date Title
US11917498B2 (en) Communication method and communications apparatus
EP3488636B1 (en) Mobile device relay service for reliable internet of things
US11064388B2 (en) Traffic distribution method through multi-access network in a network and network entity performing the same
US11178717B2 (en) Traffic distribution method through multi-access network in a network and network entity performing the same
US12089270B2 (en) Method and apparatus for establishing data transmission link and computer-readable storage medium
RU2595905C2 (ru) Терминал связи и способ связи с использованием таких терминалов
US9137268B2 (en) Method, terminal, and server for obtaining heartbeat period
CN118574246A (zh) 为冗余用户平面路径提供双连接性的方法和相关网络节点
US20150341443A1 (en) Method for keeping application online, always-online controller, and device
US20210022203A1 (en) Method for deactivating user plane connection and network entity for controlling user plane connection deactivation in network
JP7514384B2 (ja) 通信方法及び装置
CN110519809B (zh) 管理pdu会话的方法、网元、设备、装置、系统和存储介质
WO2017080422A1 (zh) 一种QoS管理的方法及装置
US20170289942A1 (en) Radio terminal, network apparatus, and method therefor
CN110754112A (zh) 终端的网络接入方法以及用于移动性支持和数据传送的方法和装置
CN112970284B (zh) 使用多个分组数据单元会话的超可靠通信
KR101920267B1 (ko) 제어 장치, 무선 통신 디바이스, 및 이들의 방법
US11882033B2 (en) Filtering ethernet device source addresses for loop avoidance
KR20190043079A (ko) 네트워크에서 하향링크 데이터를 알리는 방법, 네트워크 트리거된 서비스 요청 방법, 그리고 이를 수행하는 네트워크 엔터티
US20230370944A1 (en) Communication method and apparatus
CN111373834B (zh) 用于建立数据无线承载的客户端设备、接入网设备、方法及计算机程序
WO2020168467A1 (en) Terminal and method for performing a group communication
WO2018077313A1 (zh) 连接能力的通告方法及装置
WO2017193800A1 (zh) 一种实现QoS管理的方法及装置
US10542575B1 (en) Controlling initiation of dedicated bearer setup following failed dedicated bearer setup

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17795418

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17795418

Country of ref document: EP

Kind code of ref document: A1