CN115136651B - 切换方法和通信装置 - Google Patents
切换方法和通信装置 Download PDFInfo
- Publication number
- CN115136651B CN115136651B CN202080097000.1A CN202080097000A CN115136651B CN 115136651 B CN115136651 B CN 115136651B CN 202080097000 A CN202080097000 A CN 202080097000A CN 115136651 B CN115136651 B CN 115136651B
- Authority
- CN
- China
- Prior art keywords
- access network
- data
- network device
- multicast
- target access
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 253
- 238000004891 communication Methods 0.000 title claims abstract description 104
- 238000004590 computer program Methods 0.000 claims description 14
- 230000001902 propagating effect Effects 0.000 claims 1
- 230000005540 biological transmission Effects 0.000 description 443
- 239000003550 marker Substances 0.000 description 219
- 230000006870 function Effects 0.000 description 52
- 230000008569 process Effects 0.000 description 46
- 230000006399 behavior Effects 0.000 description 39
- 238000007726 management method Methods 0.000 description 39
- 238000012545 processing Methods 0.000 description 32
- 230000004044 response Effects 0.000 description 24
- 238000013507 mapping Methods 0.000 description 22
- 238000005516 engineering process Methods 0.000 description 19
- 238000010586 diagram Methods 0.000 description 17
- 238000013461 design Methods 0.000 description 14
- 238000005259 measurement Methods 0.000 description 12
- 230000004048 modification Effects 0.000 description 11
- 238000012986 modification Methods 0.000 description 11
- 230000001360 synchronised effect Effects 0.000 description 9
- 230000011664 signaling Effects 0.000 description 8
- 230000009471 action Effects 0.000 description 6
- 230000009286 beneficial effect Effects 0.000 description 5
- 238000001914 filtration Methods 0.000 description 5
- 238000002360 preparation method Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 4
- 238000010295 mobile communication Methods 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000013523 data management Methods 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000005641 tunneling Effects 0.000 description 3
- 230000003190 augmentative effect Effects 0.000 description 2
- 238000013475 authorization Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0009—Control or signalling for completing the hand-off for a plurality of users or terminals, e.g. group communication or moving wireless networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0007—Control or signalling for completing the hand-off for multicast or broadcast services, e.g. MBMS
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本申请提供了一种切换方法和通信装置。该方法包括:目标接入网设备获取第一消息和用于传输多播数据的信息;该第一消息用于请求为终端设备切换至目标接入网设备建立资源;该目标接入网设备发送第二消息,该第二消息用于指示目标接入网设备上已建立的资源;接收来自用户面网元的第一数据包,该第一数据包对应于所述用于传输多播数据的信息;向终端设备发送该第一数据包。从而使得终端设备在接收多播数据的情况下实现从源接入网设备至目标接入网设备的切换。
Description
技术领域
本申请涉及通信领域,并且更具体地,涉及一种切换方法和通信装置。
背景技术
目前,在某些通信***中,例如第五代(5th Generation,5G)移动通信***中,网络设备可以通过单播和广播融合(或者称“伪广播”)的传输方式为终端设备传输数据。核心网设备可以利用终端设备的单播传输路径向接入网设备传输一个多播群组的多播数据,接入网设备可通过多播方式向该多播群组中的多个终端设备传输该多播数据。
然而,由于终端设备的高移动性,终端设备在接收多播数据的同时可能会进行小区切换。终端设备在接收多播数据的情况下如何进行小区切换,成为了亟待解决的技术问题。
发明内容
本申请提供一种切换方法和通信装置,以期在终端设备接收多播数据的情况下实现从源接入网设备至目标接入网设备的切换。
第一方面,提供了一种切换方法,该方法例如可以由目标接入网设备执行,或者也可以由配置在目标接入网设备中的部件(如电路、芯片或芯片***等)执行。本申请对此不作限定。
具体地,该方法包括:获取第一消息,该第一消息用于请求为终端设备切换至目标接入网设备建立资源;获取用于传输多播数据的信息;发送第二消息,该第二消息用于指示目标接入网设备上已建立的资源;接收来自用户面网元(user plane function,UPF)的第一数据包,该第一数据包对应于所述用于传输多播数据的信息;向终端设备发送该第一数据包。
其中,用于传输多播数据的信息例如可以包括以下一项或多项:该多播数据的数据标识、与该多播数据对应的多播群组的标识、与该多播数据对应的多播会话的标识、用于传输该多播数据的协议数据单元(protocol data unit,PDU)会话的标识、用于传输该多播数据的隧道的标识、用于传输该多播数据的服务质量流(QoS Flow)的标识、该多播数据的识别信息,其中,多播数据的识别信息包括该多播数据的源网际协议(Internet Protocol,IP)地址、源端口号、目的IP地址或目的端口号中的一项或多项。
基于上述方案,终端设备可以在接收多播数据的完成从源接入网设备至目标接入网设备的切换。源接入网设备在向目标接入网设备请求建立资源的同时,可以将用于传输多播数据的信息发送给目标接入网设备,以便于目标接入网设备基于该信息,将与该信息对应的数据发送给终端设备。因此,终端设备可以在接收多播数据的同时进行切换,而不对该多播数据的接收造成影响。
可选地,所述获取第一消息,包括:从源接入网设备获取第一消息。
可选地,所述获取用于传输多播数据的信息,包括:从源接入网设备获取用于传输多播数据的信息。
可选地,所述发送第二消息,包括,向源接入网设备发送第二消息。
进一步地,该方法还包括:接收来自源接入网设备的第二数据包,该第二数据包对应于所述用于传输多播数据的信息,该第二数据包包括该第二数据包对应的第一序列号。
为了避免对多播数据的丢包,该目标接入网设备可以从源接入网设备接收该多播数据的数据包,即第二数据包。
结合第一方面,在第一方面的某些实现方式中,目标接入网设备可以根据第一数据包的序列号与来自源接入网设备的第一结束标记(End Marker)数据包的序列号的大小关系,确定是否向终端设备转发第二数据包。
可选地,该方法还包括:接收来自源接入网设备的第一结束标记(End Marker)数据包,该第一End Marker数据包包括该第一End Marker数据包对应的第二序列号。
目标接入网设备接收到该第一End Marker数据包之后,开始考虑将从UPF接收的第一数据包转发给终端设备。
可选地,若第一序列号小于第二序列号,向终端设备发送第二数据包。
可选地,所述向终端设备发送第一数据包,包括:若第一序列号大于或等于第二序列号,向终端设备发送第一数据包。
目标接入网设备可以基于对第一序列号与第二序列号的大小关系的比较,确定向终端设备转发第一数据包还是第二数据包。由此可以避免对该多播数据的丢包,有利于获得完整的数据,保证了数据传输性能。
结合第一方面,在第一方面的某些实现方式中,目标接入网设备可以根据第一数据包的序列号与第二数据包的序列号的大小关系,确定是否向终端设备转发第二数据包。在这种实现方式中,UPF例如可以通过IP多播的方式或通过多播传输通道向终端设备发送第二数据包。
可选地,第一数据包包括该第一数据包对应的第三序列号;所述向终端设备发送第一数据包,包括:若第三序列号小于或等于第一序列号,向终端设备发送第一数据包。
可选地,若第三序列号大于第一序列号,向终端设备发送第二数据包。
目标接入网设备可以基于对第一序列号和第三序列号的大小关系的比较,确定向终端设备转发第一数据包还是第二数据包。由此可以避免对该多播数据的丢包,有利于获得完整的数据,保证了数据传输性能。
结合第一方面,在第一方面的某些实现方式中,该方法还包括:向源接入网设备发送接入网隧道信息,该接入网隧道信息用于指示转发多播数据的转发隧道的标识。
在一种可能的设计中,该接入网隧道信息可以携带在上述第二消息中。此情况下,目标接入网设备发送第二消息的同时也即发送了该接入网隧道信息。即,发送接入网隧道信息的步骤和上述发送第二消息的步骤可以合为一个发送步骤。
应理解,该接入网隧道信息也可以携带在其他信令中。本申请对此不作限定。
通过向源接入网设备发送接入网隧道信息,以便于源接入网设备与目标接入网设备建立二者之间的转发隧道,从而可以实现源接入网设备向目标接入网设备转发数据包。因此,当核心网还未完成路径切换时,源接入网设备可以通过该转发隧道向目标接入网设备转发多播数据,进而由目标接入网设备发送给终端设备。因此可以避免多播数据的数据包的丢失。
这里,源接入网设备与目标接入网设备之间的转发隧道,可以是包含或者未包含核心网网元(如接入和移动管理网元(access and mobility management function,AMF)等)的隧道。例如在Xn切换场景下,该转发隧道可以不包含核心网网元;在N2切换场景下,该转发隧道可以包含核心网网元。本申请对此不作限定。
第二方面,提供了一种切换方法,该方法例如可以由源接入网设备执行,或者,也可以由配置在源接入网设备中的部件(如电路、芯片或芯片***等)执行。本申请对此不作限定。
具体地,该方法包括:发送第一消息,该第一消息用于请求为终端设备切换至目标接入网设备建立资源;向目标接入网设备发送用于传输多播数据的信息;接收第二消息,该第二消息用于指示目标接入网设备上已建立的资源;向终端设备发送第二数据包,该第二数据包对应于所述用于传输多播数据的信息。
其中,用于传输多播数据的信息例如可以包括以下一项或多项:所述多播数据的数据标识、与所述多播数据对应的多播群组的标识、与所述多播数据对应的多播会话的标识、用于传输所述多播数据的PDU会话的标识、用于传输所述多播数据的隧道的标识、用于传输所述多播数据的服务质量流的标识、所述多播数据的识别信息,其中所述多播数据的识别信息包括所述多播数据的源IP地址、源端口号、目的IP地址或目的端口号中的一项或多项。
基于上述方案,终端设备可以在接收多播数据的完成从源接入网设备至目标接入网设备的切换。源接入网设备在向目标接入网设备请求建立资源的同时,可以将用于传输多播数据的信息发送给目标接入网设备,以便于目标接入网设备基于该信息,将与该信息对应的数据发送给终端设备。因此,终端设备可以在接收多播数据的同时进行切换,而不对该多播数据的接收造成影响。
可选地,所述发送第一消息,包括:向目标接入网设备发送第一消息。
可选地,所述发送用于传输多播数据的信息,包括:向目标接入网设备发送用于传输多播数据的信息。
可选地,所述接收第二消息,包括:从目标接入网设备接收第二消息。
结合第二方面,在第二方面的某些实现方式中,该方法还包括:接收来自UPF的第二End Marker数据包,该第二End Marker数据包包括第一End Marker数据包对应的第二序列号,该第二End Marker数据包在终端设备的用于传输多播数据的通道上传输;基于接收到的第二End Marker数据包,向目标接入网设备发送第一End Marker数据包。
UPF向源接入网设备发送的第二End Marker数据包可以理解为是针对该多播数据发送的End Marker数据包。源接入网设备基于该第二End Marker数据包可以向目标接入网设备发送第一End Marker数据包,由此,目标接入网设备可以开始考虑将从UPF接收的第一数据包转发给终端设备。
应理解,第一End Marker数据包和第二End Marker数据包可以是相同的数据包,也可以是不同的数据包。本申请对此不作限定。
源接入网设备可以基于该第二End Marker数据包的序列号和从UPF接收到的第二数据包的序列号,确定是否向目标接入网设备转发第二数据包。
可选地,该方法还包括:若第一序列号小于第二序列号,向目标接入网设备发送第二数据包。
第一序列号小于第二序列号,说明在第二End Marker数据包之前还有多播数据的数据包未到达,如果直接停止向目标接入网是设备转发第二数据包可能会造成多播数据的丢包。因此,源接入网设备可以在第一序列号小于第二序列号的情况下,向目标接入网设备发送第二数据包。从而可以避免多播数据的丢包。
该第二End Marker数据包可以通过终端设备的用于传输多播数据的传输通道传输。源接入网设备可以基于预先获得的多播数据与传输通道间的映射关系,以及传输该第二End Marker数据包的传输通道确定该第二End Marker数据包是针对哪个多播数据传输的。
结合第二方面,在第二方面的某些实现方式中,该方法还包括:接收来自UPF的第二End Marker数据包,该第二End Marker数据包携带多播数据的传输通道的标识信息,该第二End Marker数据包在多播数据的传输通道上传输;基于接收到的第二End Marker数据包,向目标接入网设备发送第一End Marker数据包。
通过在第二End Marker数据包中携带多播数据的传输通道的标识信息,源接入网设备可以基于预先获得的多播数据与传输通道间的映射关系,以及传输该第二End Marker数据包的传输通道确定该第二End Marker数据包是针对哪个多播数据传输的。
第三方面,提供了一种通信方法,该方法例如可以由会话管理网元(sessionmanagement function,SMF)执行,或者,也可以由配置在SMF中的部件(如电路、芯片或芯片***等)执行。本申请对此不作限定。
具体地,该方法包括:接收第三消息,该第三消息用于指示用于传输多播数据的信息,该第三消息用于请求配置终端设备的传输通道上的数据传输,该传输通道用于传输该终端设备请求的数据,该终端设备请求的数据对应于上述用于传输多播数据的信息;发送第四消息,该第四消息用于指示对终端设备请求的数据的转发行为。
其中,用于传输多播数据的信息例如可以包括以下一项或多项:所述多播数据的数据标识、与所述多播数据对应的多播群组的标识、与所述多播数据对应的多播会话的标识、用于传输所述多播数据的PDU会话的标识、用于传输所述多播数据的隧道的标识、用于传输所述多播数据的服务质量流的标识、所述多播数据的识别信息,其中所述多播数据的识别信息包括所述多播数据的源IP地址、源端口号、目的IP地址或目的端口号中的一项或多项。
基于上述方案,由于终端设备请求的数据对应于用于传输多播数据的信息,SMF可以确定对该数据的转发行为。比如,对该终端设备请求的数据进行过滤,或者不过滤等。在终端设备在接收多播数据的同时若要切换接入网设备,则可以通过确定对数据的转发行为,保证终端设备请求的数据不丢包。可选地,所述接收第三消息,包括:从接入和移动性管理网元(access and mobility management function,AMF)接收第三消息。该第三消息例如可以是N11消息。
可选地,所述发送第四消息,包括:向UPF发送第四消息。该第四消息例如可以是N4消息。
结合第三方面,在第三方面的某些实现方式中,该第四消息包括以下任意一项或多项:针对所述终端设备请求的数据的转发行为的指示、所述用于传输所述多播数据的信息、识别规则、转发行为规则和结束标记数据包的相关信息。
SMF可以在确定了对终端设备请求的数据的转发行为之后,通过第四消息向UPF指示;也可以将用于传输多播数据的信息、识别规则、转发行为规则等信息都发送给UPF,由UPF自行确定对该终端设备请求的数据的转发行为。
该第四消息中包含的End Marker数据包的相关信息例如可以是SMF生成并发送给UPF的End Marker数据包,也可以是指示UPF生成End Marker数据包的信息。本申请对此不做限定。
第四方面,提供了一种通信方法,该方法例如可以由UPF执行,或者,也可以由配置在UPF中的部件(如电路、芯片或芯片***等)执行。本申请对此不作限定。
具体地,该方法包括:接收第四消息,该第四消息包括用于传输多播数据的信息,用于传输多播数据的信息与终端设备请求的数据对应;根据该用于传输多播数据的信息,确定对终端设备请求的数据的转发行为。
其中,用于传输多播数据的信息例如可以包括以下一项或多项:所述多播数据的数据标识、与所述多播数据对应的多播群组的标识、与所述多播数据对应的多播会话的标识、用于传输所述多播数据的PDU会话的标识、用于传输所述多播数据的隧道的标识、用于传输所述多播数据的服务质量流的标识、所述多播数据的识别信息,其中所述多播数据的识别信息包括所述多播数据的源IP地址、源端口号、目的IP地址或目的端口号中的一项或多项。
基于上述方案,由于终端设备请求的数据对应于用于传输多播数据的信息,UPF可以根据该用于传输多播数据的信息,确定对该终端设备请求的数据的转发行为。比如,对该数据进行过滤,或者不过滤等。在终端设备在接收多播数据的同时若要切换接入网设备,则可以通过确定对数据的转发行为,保证终端设备请求的数据不丢包。可选地,所述接收第四消息,包括:从SMF接收第四消息。该第四消息可以是N11消息。
结合第四方面,在第四方面的某些实现方式中,该第四消息包括以下任意一项或多项:识别规则、转发行为规则和结束标记数据包的相关信息。
关于识别规则、转发行为规则和结束标记数据包的相关信息的相关说明可参看第三方面中的相关描述,为了简洁,这里不再重复。
结合第三方面或第四方面,在某些实现方式中,该转发行为包括:在该终端设备的传输通道上传输该终端设备请求的数据。
终端设备在接收多播数据的时候,其所请求的数据可能在UPF侧或RAN侧被合并,或者说被过滤。SMF或UPF可以在该终端设备切换时确定对该数据的转发行为,使得终端设备在切换到目标接入网设备之后,所请求的数据不被过滤。也即,终端设备在切换到目标接入网设备之后可以通过自己的传输通道接收它所请求的数据。
对于UPF来说,在确定了对该终端设备请求的数据的转发行为之后,便可以在该终端设备的传输通道上传输该终端设备请求的数据。
结合第三方面或第四方面,在某些实现方式中,该第四消息还用于指示在该终端设备的传输通道上传输第二End Marker数据包。
结合第三方面或第四方面,在某些实现方式中,该第四消息还用于指示在多播数据的传输通道上传输所述第二End Marker数据包。
上文列举了两种传输第二End Marker数据包的传输通道。即,在前一种实现方式中,该第二End Marker数据包与终端设备请求的数据在同一个传输通道中传输;在后一种实现方式中,该第二End Marker数据包在多播数据的传输通道上传输,也即与终端设备请求的数据不在同一个传输通道上传输。
可选地,该第四消息中还包括:所述终端设备的传输通道的标识信息。
在该第四消息中携带该终端设备的传输通道的标识信息,可以便于源接入网设备确定该第二End Marker数据包是针对哪个终端设备的哪个数据发送的,或者说,是针对哪个多播数据发送的,进而可以通过相应的转发隧道向目标接入网设备发送第一End Marker数据包。
结合第三方面或第四方面,在某些可能的实现方式中,在所述终端设备由源接入网设备切换至目标接入网设备之前,所述终端设备的传输通道是所述用户面网元与所述源接入网设备之间的通道;在所述终端设备由源接入网设备切换至目标接入网设备之后,所述终端设备的传输通道是所述用户面网元与所述目标接入网设备之间的通道。
应理解,第三方面和第四方面所提供的方法并不仅限于在终端设备切换时使用。SMF可以利用上述方法确定终端设备请求的数据的不同的转发行为。本申请对于该方法所适用的范围不作限定。
第五方面,提供了一种通信装置,包括用于执行第一方面至第四方面任一种可能实现方式中的方法的各个模块或单元。
第六方面,提供了一种通信装置,包括处理器。该处理器与存储器耦合,可用于执行存储器中的指令或者数据,以实现上述第一方面至第四方面任一种可能实现方式中的方法。可选地,该通信装置还包括存储器。可选地,该通信装置还包括通信接口,处理器与通信接口耦合。
在一种实现方式中,该通信装置为终端设备。当该通信装置为终端设备时,所述通信接口可以是收发器,或,输入/输出接口。
在另一种实现方式中,该通信装置为配置于终端设备中的芯片。当该通信装置为配置于终端设备中的芯片时,所述通信接口可以是输入/输出接口。
可选地,所述收发器可以为收发电路。可选地,所述输入/输出接口可以为输入/输出电路。
第七方面,提供了一种处理器,包括:输入电路、输出电路和处理电路。所述处理电路用于通过所述输入电路接收信号,并通过所述输出电路发射信号,使得所述处理器执行第一方面至第四方面中任一种可能实现方式中的方法。
在具体实现过程中,上述处理器可以为一个或多个芯片,输入电路可以为输入管脚,输出电路可以为输出管脚,处理电路可以为晶体管、门电路、触发器和各种逻辑电路等。输入电路所接收的输入的信号可以是由例如但不限于接收器接收并输入的,输出电路所输出的信号可以是例如但不限于输出给发射器并由发射器发射的,且输入电路和输出电路可以是同一电路,该电路在不同的时刻分别用作输入电路和输出电路。本申请实施例对处理器及各种电路的具体实现方式不做限定。
第八方面,提供了一种处理装置,包括处理器和存储器。该处理器用于读取存储器中存储的指令,并可通过接收器接收信号,通过发射器发射信号,以执行第一方面至第四方面任一种可能实现方式中的方法。
可选地,所述处理器为一个或多个,所述存储器为一个或多个。
可选地,所述存储器可以与所述处理器集成在一起,或者所述存储器与处理器分离设置。
在具体实现过程中,存储器可以为非瞬时性(non-transitory)存储器,例如只读存储器(read only memory,ROM),其可以与处理器集成在同一块芯片上,也可以分别设置在不同的芯片上,本申请实施例对存储器的类型以及存储器与处理器的设置方式不做限定。
应理解,相关的数据交互过程例如发送指示信息可以为从处理器输出指示信息的过程,接收能力信息可以为处理器接收输入能力信息的过程。具体地,处理器输出的数据可以输出给发射器,处理器接收的输入数据可以来自接收器。其中,发射器和接收器可以统称为收发器。
上述第八方面中的处理装置可以是一个或多个芯片。该处理装置中的处理器可以通过硬件来实现也可以通过软件来实现。当通过硬件实现时,该处理器可以是逻辑电路、集成电路等;当通过软件来实现时,该处理器可以是一个通用处理器,通过读取存储器中存储的软件代码来实现,该存储器可以集成在处理器中,可以位于该处理器之外,独立存在。
第九方面,提供了一种计算机程序产品,所述计算机程序产品包括:计算机程序(也可以称为代码,或指令),当所述计算机程序被运行时,使得计算机执行上述第一方面至第四方面中任一种可能实现方式中的方法。
第十方面,提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序(也可以称为代码,或指令)当其在计算机上运行时,使得计算机执行上述第一方面至第四方面中任一种可能实现方式中的方法。
第十一方面,提供了一种通信***,包括前述的源接入网设备、目标接入网设备、SMF、UPF和终端设备中的一个或多个。
附图说明
图1是适用于本申请实施例提供的切换方法的网络结构的示意图;
图2和图3示出了本申请实施例提供的多播的具体实现流程;
图4是本申请一实施例提供的切换方法的示意性流程图;
图5是本申请一实施例提供的切换方法的示意图;
图6是本申请另一实施例提供的切换方法的示意性流程图;
图7是本申请另一实施例提供的切换方法的示意图;
图8是本申请又一实施例提供的切换方法的示意性流程图;
图9是本申请又一实施例提供的切换方法的示意图;
图10是本申请再一实施例提供的切换方法的示意性流程图;
图11是本申请实施例提供的Xn切换的部分流程的示意图;
图12和图13是本申请实施例提供的N2切换的部分流程的示意图;
图14是本申请实施例提供的通信装置的示意性框图;
图15是本申请实施例提供的通信装置的另一示意性框图;
图16是本申请实施例提供的接入网设备的结构示意图。
具体实施方式
下面将结合附图,对本申请中的技术方案进行描述。
本申请提供的技术方案可以应用于各种通信***,例如:第五代(5thGeneration,5G)移动通信***或新无线接入技术(new radio access technology,NR)。其中,5G移动通信***可以包括非独立组网(non-standalone,NSA)和/或独立组网(standalone,SA)。
本申请提供的技术方案还可以应用于机器类通信(machine typecommunication,MTC)、机器间通信长期演进技术(Long Term Evolution-machine,LTE-M)、设备到设备(device-to device,D2D)网络、机器到机器(machine to machine,M2M)网络、物联网(internet of things,IoT)网络或者其他网络。其中,IoT网络例如可以包括车联网。其中,车联网***中的通信方式统称为车到其他设备(vehicle to X,V2X,X可以代表任何事物),例如,该V2X可以包括:车辆到车辆(vehicle to vehicle,V2V)通信,车辆与基础设施(vehicle to infrastructure,V2I)通信、车辆与行人之间的通信(vehicle topedestrian,V2P)或车辆与网络(vehicle to network,V2N)通信等。
本申请提供的技术方案还可以应用于未来的通信***,如第六代移动通信***等。本申请对此不作限定。
图1是适用于本申请实施例提供的方法的网络架构的示意图。如图1所示,该网络架构例如是第三代合作伙伴计划(3rd Generation Partnership Project,3GPP)协议TS23.501中定义的5G***(the 5h generation system,5GS)。该网络架构可以分为接入网(access network,AN)和核心网(core network,CN)两部分。其中,接入网可用于实现无线接入有关的功能,核心网主要包括以下几个关键逻辑网元:接入和移动性管理网元(accessand mobility management function,AMF)、会话管理网元(session managementfunction,SMF)、用户面网元(user plane function,UPF)、策略控制网元(policy controlfunction,PCF)和统一数据管理网元(unified data management,UDM)等。
下面对图1中示出的各网元做简单介绍:
1、用户设备(user equipment,UE):可以称终端设备、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。
终端设备可以是一种向用户提供语音/数据连通性的设备,例如,具有无线连接功能的手持式设备、车载设备等。目前,一些终端的举例可以为:手机(mobile phone)、平板电脑(pad)、带无线收发功能的电脑(如笔记本电脑、掌上电脑等)、移动互联网设备(mobileintemet device,MID)、虚拟现实(virtual reality,VR)设备、增强现实(augmentedreality,AR)设备、工业控制(industrial control)中的无线终端、无人驾驶(selfdriving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smartgrid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smartcity)中的无线终端、智慧家庭(smart home)中的无线终端、蜂窝电话、无绳电话、会话启动协议(session initiation protocol,SIP)电话、无线本地环路(wireless local loop,WLL)站、个人数字助理(personal digital assistant,PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备,5G网络中的终端设备或者未来演进的公用陆地移动通信网络(public land mobile network,PLMN)中的终端设备等。
此外,终端设备还可以是物联网(Internet of things,IoT)***中的终端设备。IoT是未来信息技术发展的重要组成部分,其主要技术特点是将物品通过通信技术与网络连接,从而实现人机互连,物物互连的智能化网络。IoT技术可以通过例如窄带(narrowband)NB技术,做到海量连接,深度覆盖,终端省电。
此外,终端设备还可以包括智能打印机、火车探测器、加油站等传感器,主要功能包括收集数据(部分终端设备)、接收网络设备的控制信息与下行数据,并发送电磁波,向网络设备传输上行数据。
2、接入网(access network,AN):接入网可以为特定区域的授权用户提供入网功能,并能够根据用户的级别、业务的需求等使用不同质量的传输隧道。接入网络可以为采用不同接入技术的接入网络。目前的无线接入技术有两种类型:3GPP接入技术(例如3G、4G或5G***中采用的无线接入技术)和非3GPP(non-3GPP)接入技术。3GPP接入技术是指符合3GPP标准规范的接入技术,例如,5G***中的接入网设备称为下一代基站节点(nextgeneration Node Base station,gNB)。非3GPP接入技术是指不符合3GPP标准规范的接入技术,例如,以无线保真(wireless fidelity,WiFi)中的接入点(access point,AP)为代表的空口技术。
基于无线通信技术实现接入网络功能的接入网可以称为无线接入网(radioaccess network,RAN)。无线接入网能够管理无线资源,为终端设备提供接入服务,进而完成控制信号和用户数据在终端和核心网之间的转发。
无线接入网例如可以包括但不限于:无线网络控制器(radio networkcontroller,RNC)、节点B(Node B,NB)、基站控制器(base station controller,BSC)、基站收发台(base transceiver station,BTS)、家庭基站(例如,home evolved NodeB,或homeNode B,HNB)、基带单元(baseband unit,BBU),WiFi***中的AP、无线中继节点、无线回传节点、传输点(transmission point,TP)或者发送接收点(transmission and receptionpoint,TRP)等,还可以为5G(如,NR)***中的gNB或传输点(TRP或TP),5G***中的基站的一个或一组(包括多个天线面板)天线面板,或者,还可以为构成gNB或传输点的网络节点,如基带单元(BBU),或,分布式单元(distributed unit,DU),或者下一代通信6G***中的基站等。本申请实施例对无线接入网设备所采用的具体技术和具体设备形态不做限定。
接入网可以为小区提供服务。终端设备可以通过接入网设备分配的传输资源(例如,频域资源,或者说,频谱资源)与小区通信。
3、接入和移动性管理网元(AMF):主要用于移动性管理和接入管理等,如用户位置更新、用户注册网络、用户切换等。AMF还可用于实现移动性管理实体(mobilitymanagement entity,MME)中除会话管理之外的其它功能。例如,合法监听、或接入授权(或鉴权)等功能。
4、会话管理网元(SMF):主要用于会话管理、UE的网际协议(Internet Protocol,IP)地址分配和管理、选择可管理用户平面功能、策略控制、或收费功能接口的终结点以及下行数据通知等。在本申请实施例中,SMF主要用户负责移动网络中的会话管理,如会话建立、修改、释放等。具体功能例如可以包括为终端设备分配IP地址、选择提供报文转发功能的UPF等。
5、用户面网元(UPF):即,数据面网关。可用于分组路由和转发、或用户面数据的服务质量(quality of service,QoS)处理等。用户数据可通过该网元接入到数据网络(datanetwork,DN)。在本申请实施例中,可用于实现用户面网关的功能。
6、数据网络(DN):用于为用户提供数据服务的运营商网络。例如,运营商业务的网络、因特网(Internet)、第三方的业务网络、IP多媒体服务业务(IP multi-media service)网络等。
7、认证服务网元(authentication server function,AUSF):主要用于用户鉴权等。
8、网络开放网元(network exposure function,NEF):用于安全地向外部开放由3GPP网络功能提供的业务和能力等。
9、网络存储网元((network function(NF)repository function,NRF):用于保存网络功能实体以及其提供服务的描述信息,以及支持服务发现,网元实体发现等。
10、策略控制功能网元(PCF):用于指导网络行为的统一策略框架,为控制平面功能网元(例如AMF,SMF网元等)提供策略规则信息等。
11、统一数据管理网元(UDM):用于存储用户数据,如签约信息、鉴权/授权信息等。
12、应用功能网元(application function,AF):负责向3GPP网络提供业务,如影响业务路由、与PCF之间交互以进行策略控制等。
在图1所示的网络架构中,各网元之间可以通过图中所示的接口通信。如图所示,N1接口为终端设备与AMF之间的参考点;N2接口为RAN和AMF的参考点,用于非接入层(non-access stratum,NAS)消息的发送等;N3接口为RAN和UPF之间的参考点,用于传输用户面的数据等;N4接口为SMF和UPF之间的参考点,用于传输例如N3连接的隧道标识信息,数据缓存指示信息,以及下行数据通知消息等信息;N6接口为UPF和DN之间的参考点,用于传输用户面的数据等。其他接口与各网元之间的关系如图1中所示,为了简洁,这里不一一详述。
应理解,上述应用于本申请实施例的网络架构仅是举例说明的从传统点到点的架构和服务化架构的角度描述的网络架构,适用本申请实施例的网络架构并不局限于此,任何能够实现上述各个网元的功能的网络架构都适用于本申请实施例。
还应理解,图1中所示的AMF、SMF、UPF、网络切片选择功能网元(network sliceselection function,NSSF)、NEF、AUSF、NRF、PCF、UDM可以理解为核心网中用于实现不同功能的网元,例如可以按需组合成网络切片。这些核心网网元可以各自独立的设备,也可以集成于同一设备中实现不同的功能,本申请对于上述网元的具体形态不作限定。
还应理解,上述命名仅为便于区分不同的功能而定义,不应对本申请构成任何限定。本申请并不排除在5G网络以及未来其它的网络中采用其他命名的可能。例如,在6G网络中,上述各个网元中的部分或全部可以沿用5G中的术语,也可能采用其他名称等。图1中的各个网元之间的接口名称只是一个示例,具体实现中接口的名称可能为其他的名称,本申请对此不作具体限定。此外,上述各个网元之间的所传输的消息(或信令)的名称也仅仅是一个示例,对消息本身的功能不构成任何限定。
为便于理解本申请实施例,首先对本申请中涉及到的术语做简单说明。
1、协议数据单元(protocol data unit,PDU)会话(PDU session):5G核心网(5Gcorenet,5GC)支持PDU连接业务。PDU连接业务可以是指终端设备与DN之间交换PDU数据包的业务。PDU连接业务通过终端设备发起PDU会话的建立来实现。一个PDU会话建立后,也就是建立了一条终端设备和DN的数据传输通道。换句话说,PDU会话是UE级别的。每个终端设备可以建立一个或多个PDU会话。
如前所述,SMF主要用户负责移动网络中的会话管理。PDU会话在终端设备和SMF之间可以通过NAS会话管理(session management,SM)信令进行建立、修改或释放。
在本申请实施例中,一个PDU会话可以通过一个PDU会话标识(PDU sessionidentifier,PDU session ID)来标识。由于PDU会话是UE级别的,因此每个PDU会话标识也可对应于一个终端设备。
2、隧道(tunnel):核心网与接入网之间可以基于GPRS隧道协议(GPRS tunnelprotocol,GTP)来实现数据传输。在本申请实施例中,隧道可以理解为是PDU会话中更小粒度的传输通道,可用于传输GTP数据包。
3、QoS流(QoS Flow):QoS Flow是PDU会话中最精细的QoS区分粒度。在5G***中,一个QoS Flow标识(QoS Flow identifier,QFI)可用于标识一条QoS Flow。一个PDU会话中可以包括多条QoS Flow,但每条QoS Flow的QFI都是不同的。换言之,一个QFI在一个PDU会话中是唯一的。
4、单播和多播融合:也可以称为“伪广播”。在5G核心网(5G corenet,5GC)中,利用终端设备的单播传输路径进行传输,但该单播传输路径上传输的数据可以被多个终端设备接收。由于多个终端设备接收同一单播传输路径上传输的数据,就好像接收广播数据一样,因此将该传输模式称为“伪广播”。换言之,核心网通过单播的方式实现了多播数据的传输,并可以支持在接入网侧空口的多播。因此单播和多播融合可以视为核心网实现多播的一种技术。
本申请实施例提供的技术方案主要涉及核心网与接入网之间的多播数据的传输的改进,而对接入网设备与终端设备之间的空口传输并没有改动。由于核心网可以通过单播的方式实现空口的多播,故可以将该核心网和接入网设备之间传输的、可实现空口多播的数据成为多播数据。下文中所述的多播数据、多播群组、多播会话等描述均是针对核心网与接入网设备之间传输的数据而言的,不应对接入网侧在空口传输的数据构成限定。
但需要注意的是,伪广播并不同于传统意义上的广播。传统的广播需要建立专门的广播信道。而伪广播仅需使用某一终端设备的单播传输路径,或者使用公共的传输路径便可以实现。
用于传输多播数据的PDU会话可以称为多播会话,接收同一多播数据的多个终端设备可以属于一个多播群组。也就是说,一个多播数据可以对应一个多播群组,或者说,一个多播会话。
一个多播群组可以包括一个或多个终端设备。同一多播群组中的终端设备为多个时,该多个终端设备可能是驻留在同一小区的终端设备,也可能是驻留在多个不同小区中的终端设备。本申请对此不作限定。
同一个多播数据可以通过一个数据标识来指示。同一个多播群组也可以通过一个多播群组的标识来指示。同一个多播会话也可以通过一个多播会话的标识来指示。换言之,多播数据的数据标识与多播群组的标识和多播会话的标识具有对应关系。
应理解,这里仅为便于理解和说明,引入了多播数据的数据标识、多播群组的标识以及多播会话的标识。在实际的传输配置过程中,上述多播数据的数据标识、多播群组的标识以及多播会话的标识可能并不一定都会配置。由于三者间一一对应的关系,因此可以认为,多播数据的数据标识、多播群组的标识和多播会话的标识是可替换的,或者说,等价的。
多播的前提条件可以是,对于某些应用(application,APP),例如发送直播业务的APP),核心网可以依据识别信息识别其传输的数据是否属于同一个多播群组,或者说,是否为针对同一多播群组而传输的数据。
这里,核心网所依据的识别信息例如可以是源IP地址、目的IP地址、源端口号和目的端口中的一项或多项。比如,该识别信息具体可以是:源IP地址,或源端口号,或源IP地址和源端口号,或目的IP地址,或目的端口号,或目的IP地址和目的端口号,或源IP地址、源端口号、目的IP地址和目的端口号。
在本申请实施例中,当终端设备向核心网发送请求时,可以同时携带上述识别信息、或者,也可以携带多播群组的标识信息、多播数据的标识信息和多播会话的标识信息中的一种或多种。核心网可以基于上述识别信息确定该终端设备所请求传输的数据是否可以通过多播的方式传输。
具体来说,若核心网确定终端设备请求传输的数据#1和数据#2具有相同的识别信息,则可以确定请求该数据#1和数据#2的终端设备属于同一多播群组。比如,若数据#1和数据#2的源IP地址相同,则可确定请求该数据#1和数据#2的终端设备属于同一多播群组;或,若数据#1和数据#2的目的IP地址相同,则可确定请求该数据#1和数据#2的终端设备属于同一多播群组;或,若数据#1和数据#2的源IP地址相同,且数据#1和数据#2的源端口号也相同,则可确定请求该数据#1和数据#2的终端设备属于同一多播群组;或,若数据#1和数据#2的目的IP地址相同,且数据#1和数据#2的目的端口号相同,则可确定请求该数据#1和数据#2的终端设备属于同一多播群组;或,若数据#1和数据#2的源IP地址相同,数据#1和数据#2的源端口号也相同,数据#1和数据#2的目的IP地址相同,且数据#1和数据#2的目的端口号也相同,则可确定请求该数据#1和数据#2的终端设备属于同一多播群组。为了简洁,这里不一一举例说明。其中,若数据#1和数据#2的源IP地址相同,和/或,数据#1和数据#2的源端口号相同,可以认为数据#1和数据#2是来源于同一应用服务器的数据。换言之,应用服务器的标识信息也可以理解为是识别信息的一种。
应理解,上文仅为便于理解,以数据#1和数据#2为例来说明识别信息与多播群组,但这不应对本申请构成任何限定。本申请对于多播群组中的终端设备数量不作限定,数据#1和数据#2可理解为是多播群组中的任意两个终端设备请求的数据的两个示例。通过多播的方式传输数据的具体实现方式可以如下:PCF可以根据上文所述的终端设备向核心网发送请求时所携带的识别信息生成携带该识别信息的PCC规则。SMF可以根据该PCC规则中的识别信息创建特殊的映射规则,将识别信息对应的数据映射到一个QoS Flow上。从而可以确保在一个PDU会话中,一个应用的一个直播内容可以被映射到同一个QoS Flow上。当直播内容被映射到一个QoS Flow上,该QoS Flow便承载了多播数据。
在本申请实施例中,用于承载多播数据的QoS Flow可以是多播专用PDU会话中的一个QoS Flow;也可以是多播专用隧道中的一个QoS Flow;也可以是一个多播专用QoSFlow;还可以是一个单播QoS Flow,但该QoS Flow中携带了一指示信息,用于指示该QoSFlow中承载了多播数据。
需要说明的是,多播专用PDU会话可以是指,针对该多播数据专门创建的PDU会话。所谓多播专用PDU会话,也就是说,该PDU会话不会与单播数据或其他多播数据共享。该PDU会话可以是针对某一终端设备创建,也可以是针对该多播群组创建,本申请对此不作限定。该多播专用PDU会话中可以包含针对该多播数据而创建的多播专用隧道,其中的QoS Flow是专用于承载多播数据的QoS Flow。
多播专用隧道可以是指,针对该多播数据专门创建的隧道。该多播专用隧道可以是多播专用PDU会话中的一个隧道,也可以是非多播专用PDU会话中的一个隧道,比如可以是单播PDU会话中针对该多播群组创建的一个隧道。该多播专用隧道中的QoS Flow可以是专用于承载多播数据的QoS Flow。
多播专用QoS Flow可以是指,针对该多播数据专门创建的QoS Flow。该多播专用QoS Flow可以是多播专用PDU会话中的QoS Flow,也可以是非多播专用PDU会话中的QoSFlow,比如可以是单播PDU会话中针对该多播群组创建的一个QoS Flow。为便于理解,下文结合图2和图3简单介绍多播的具体实现流程。
图2示出了多播数据在UPF侧合并的示意图。
步骤1、在PDU会话建立或修改过程中,也即UE向应用服务器请求数据的过程中,SMF可以向UPF发送识别规则(packet detection rule,PDR)和转发行为规则(forwardingaction rule,FAR)。其中,识别规则可用于指示UPF识别数据对应于哪个多播群组。转发行为规则可用于指示UPF是否对数据进行转发以及在哪个传输通道上转发。
需要说明的是,识别数据对应于哪个多播群组,可以依据该数据的识别信息来确定。
在一种可能的实现方式中,在PDU会话建立或修改之前,也即,UE向应用服务器请求数据之前,应用服务器可以向核心网(例如NEF)发送一个或多个多播会话的请求。为方便说明,下面以一个多播会话的请求为例。该请求中可以携带一个多播会话的部分识别信息,例如可以包括该应用服务器的IP地址和/或端口号。发送该多播会话的请求的应用服务器的IP地址和/端口号可以作为该多播会话的源IP地址和/或源端口号。
NEF可以向应用服务器返回该多播会话的入口信息。例如,NEF可以为该多播会话配置UPF,并返回该UPF的IP地址和/或端口号。为该多播会话配置的UPF的IP地址和/或端口号可以作为该多播会话的目的IP地址和/或目的端口号。
由此,NEF可以获取该多播会话的源IP地址和/或源端口号与目的IP地址和/或目的端口号的对应关系。NEF可以将该对应关系发送至SMF,例如在UE请求数据的过程中发送,或者,在获取到该对应关系之后就发送,不管UE是否请求数据。NEF也可以将该对应关系发送至其他用于存储的网元,例如UDM、统一数据存储库(Unified Data Repository,UDR)等。
在PDU会话建立或修改过程中,SMF可以基于UE的请求,进一步确定UE请求的多播数据与上述识别信息的对应关系。可选地,SMF可以将该对应关系作为识别规则发送给UPF。下表示出了该多播数据与上述识别信息的对应关系的一例。应理解,下表仅为便于理解而示例,不应对本申请构成任何限定。上述对应关系也并不一定以表格的形式存在。
序号 | 多播数据的标识信息 | 识别信息 |
1 | 标识1 | 源IP地址1、源端口号1、目的IP地址1、目的端口号1 |
2 | 标识2 | 源IP地址2、源端口号2、目的IP地址2、目的端口号2 |
…… | …… | …… |
是否对数据进行转发以及在哪个传输通道上转发可以依据多播数据与传输通道的映射关系来确定。
再一示例中,SMF可以不向UPF发送多播数据的标识信息,仅向UPF发送识别信息,这时SMF还会向UPF发送下述配置信息。
在PDU会话建立或修改过程中,SMF可以分别向UPF和RAN发送配置信息,例如以PDU会话为粒度,向UPF和RAN发送配置信息。该配置信息中可以包含多播数据与传输通道的映射关系的指示、多播数据的指示或者传输通道的指示的一项或多项。其中,对多播数据的指示例如可以是上述多播数据的数据标识、多播群组的标识或多播会话的标识中的一项或多项。对传输通道的指示例如可以是多播专用PDU会话标识、多播专用隧道标识或QoS Flow标识(即QFI)中的一项或多项。本申请对此不作限定。其中,多播数据、多播群组和多播会话的关系在上文中已经说明,为了简洁,这里不再重复。SMF可以预先确定多播数据与多播群组和/或多播会话的对应关系。
一种示例中,SMF向UPF发送识别信息和配置信息的对应关系。下表示出了SMF向UPF发送的识别信息和配置信息的对应关系。应理解,下表仅为便于理解而示例,不应对本申请构成任何限定。上述对应关系也并不一定以表格的形式存在。
序号 | 配置信息 | 识别信息 |
1 | 配置信息1 | 源IP地址1、源端口号1、目的IP地址1、目的端口号1 |
2 | 配置信息2 | 源IP地址2、源端口号2、目的IP地址2、目的端口号2 |
…… | …… | …… |
下文示出了配置信息的几个示例。
一示例,当用于承载多播数据的QoS Flow为多播专用PDU会话中的QoS Flow时,该多播数据与传输通道的映射关系可以是多播数据的指示与多播专用PDU会话标识的映射关系;另一示例,当用于承载多播数据的QoS Flow为多播专用隧道中的QoS Flow时,该多播数据与传输通道的映射关系可以是多播数据的指示与隧道标识的映射关系;再一示例,该多播数据与传输通道的映射关系可以是多播指示的指示与QFI的映射关系。
应理解,上文多个示例仅为便于理解而示出,不应对本申请构成任何限定。
若SMF针对多个终端设备的请求而向UPF和RAN发送的配置信息中包含了相同的多播数据的指示,则UPF和RAN可以确定该多个终端设备属于同一多播群组。
RAN可以向同一多播群组中的每个终端设备发送RRC消息,在该RRC消息中携带组无线网络临时标识(group-radio network temporary identifier,G-RNTI),以便于该多播群组中的各终端设备基于该G-RNTI接收数据。
应理解,终端设备基于G-RNTI接收数据的具体过程与终端设备基于C-RNTI接收数据的具体过程相似,由于终端设备基于C-RNTI接收数据的具体过程为现有技术。为了简洁,这里不作详述。
在本申请实施例中,上述配置信息可以基于RAN而定义。例如,该SMF可以基于每个RAN确定配置信息,每个配置信息中包含的多播群组所对应的数据可以是通过该RAN传输的数据,或者说,可以与该RAN提供服务的小区中传输的数据对应。同一个RAN中的同一个数据标识,可以与一个或多个QoS Flow对应。但应理解,若某一个数据标识所对应的QoS Flow为多个时,这并不代表该数据标识所对应的数据被映射到了该多个QoSFlow上传输,而是说,与该数据标识对应的多个QoS Flow可以用于传输内容相同的数据。但如后文所述,该多个QoS Flow中可能存在部分或全部的QoS Flow中的数据被过滤。
步骤2、UPF向RAN发送数据。
应用服务器可以基于多个终端设备的请求,向UPF发送数据。若多个终端设备请求的数据是内容相同的数据,则应用服务器可以针对每个终端设备分别发送单播数据,如图2中所示;应用服务器也可以针对该多个终端设备的请求发送数据至UPF,由UPF将该数据复制为多份,得到针对多个终端设备的多份单播数据。
应理解,图2所示仅为一种可能的实现方式,不应对本申请构成任何限定。例如在另一种实现方式中,应用服务器也可以仅向UPF发送一份数据。本申请对此不作限定。
UPF在向RAN发送数据时,可以根据SMF发送的映射关系,将每个PDU会话中对应于同一个多播群组的数据合并在一起发送。具体来说,UPF可以通过某一个终端设备的PDU会话中的QoS Flow来传输该数据标识所标识的数据,或者,网络可以单独建立一条专用的QoSFlow来传输数据。
如前所述,UPF可能从应用服务器接收到一份数据,也可能从应用服务器接收到多份数据,且该多份数据是对应于同一数据标识的数据。UPF在接收到多份数据的情况下,若UPF通过某一个终端设备的PDU会话中的QoS Flow来传输数据,UPF可以将其他对应于该数据标识的QoS Flow中的数据过滤,或者说,丢弃。换言之,其他对应于该数据标识的QoSFlow可以不传输数据。若UPF通过单独建立的一条专用QoS Flow来传输数据,UPF可以将对应于该数据标识的每个终端设备的QoS Flow中传输的数据过滤,或者说,丢弃。换言之,其他对应于该数据标识的QoS Flow可以不传输数据。举例来说,假设映射关系中包含有数据标识1及其对应的QoS Flow。比如,数据标识1对应于UE 1的QoS Flow 1,UE 2的QoS Flow2,UE 3的QoS Flow 3,UE 4的QoS Flow 4。这表示,UE 1的QoS Flow 1,UE 2的QoS Flow 2,UE 3的QoS Flow 3以及UE 4的QoS Flow 4上传输的数据内容相同,都是由数据标识1所标识的数据。UPF可以选择QoS Flow 1、QoS Flow 2、QoS Flow 3和QoS Flow 4中的任意一个QoS Flow来传输数据,例如选择QoS Flow 1来传输数据。若UPF从应用服务器接收到多份对应于数据标识1的数据,该多份数据原本可通过QoS Flow 2、QoS Flow 3和QoS Flow 4传输,但此时,UPF可以将QoS Flow 2、QoS Flow 3和QoS Flow 4中的数据过滤,或者说,丢弃,或者说,不传输数据。或者,网络也可以单独建立一条专用的QoS Flow,来传输数据。若UPF从应用服务器接收到多份对应于数据标识1的数据,该多份数据原本可通过QoS Flow 1、QoS Flow 2、QoS Flow3和QoS Flow 4,但此时,UPF可以而将QoS Flow 1、QoS Flow 2、QoSFlow 3和QoS Flow4中传输的数据过滤,或者说,丢弃,或者说,不传输数据。
应理解,这里所说的将某一QoS Flow中传输的数据丢弃,并不代表将该QoS Flow丢弃。该QoS Flow仍然存在于终端设备的PDU会话中,只是原本需要通过该QoS Flow传输的数据通过其他QoS Flow传输了。
UPF还可以在向RAN发送的通用分组无线服务隧道协议用户面(general packetradio service tunneling protocol user,GTP-U)包头中携带一个特殊的标识,以用于指示该UPF中存在数据标识相同的QoS Flow,且UPF选择了其中某一个QoS Flow发送。
步骤3、RAN向终端设备转发来自UPF的QoS Flow。
RAN接收到来自UPF的QoS Flow和GTP-U包头的标识时,便可以基于预先确定的与该QoS Flow对应的多播群组,将该QoS Flow中承载的数据发送给该多播群组中的各终端设备。RAN在发送时,可以将上述数据通过共享资源发送给多个终端设备,也可以单独地发送给某个特定终端设备,在此并不做限制。
图3是多播数据在RAN侧合并的示意图。
在步骤1中,SMF也可以向RAN发送配置信息,而不向UPF发送该配置信息。RAN可以基于该配置信息确定同一多播群组中的终端设备。
在步骤2中,UPF可以以单播形式向RAN发送与各终端设备对应的数据。即,在各终端设备的PDU会话中由UPF至RAN的QoS Flow中均承载了相同的数据。
在步骤3中,RAN将对应于同一多播群组的数据合并发送给该多播群组中的各终端设备。
在RAN侧合并的过程与上文在UPF侧合并的过程基本相似,只是将UPF对数据进行合并的步骤转由RAN来执行。为了简洁,这里省略对相同或相似内容的描述。
由于终端设备的高移动性,终端设备可能在多个小区之间频繁切换。但终端设备在接收多播数据的情况下如何完成切换,仍有待解决。
本申请提供了一种切换方法,为多播场景下的终端设备提供了多种可能的切换流程,以解决终端设备在接收多播数据的情况下如何完成切换的问题。
下面结合多个附图来详细说明本申请实施例提供的切换方法。
应理解,下文仅为便于理解和说明,以设备之间的交互为例详细说明本申请实施例所提供的方法。但这不应对本申请提供的方法的执行主体构成任何限定。例如,下文实施例示出的接入网设备可以替换为配置于接入网设备中的部件(如电路、芯片或芯片***等)。
下文示出的实施例并未对本申请实施例提供的方法的执行主体的具体结构特别限定,只要能够通过运行记录有本申请实施例的提供的方法的代码的程序,以根据本申请实施例提供的方法实现终端设备的切换即可。
此外,附图中仅为便于理解,将UPF、SMF、AMF等核心网网元单独示出,但这不应对本申请构成任何限定。本申请对于核心网网元的具体形态不作限定。
为了更好地理解本申请实施例,首先做出如下几点说明:
第一,为方便理解和说明,做出如下假设和定义:
UE1:源小区中接收多播数据的终端设备。
UE2:源小区中接收同一多播数据的终端设备,与UE1属于同一个多播群组。在本申请实施例中,UE2即将从源接入网设备切换到目标接入网设备的终端设备。
多播数据:包括UE2在进行切换前接收到的该多播群组对应的数据,即该UE2在源小区中接收到的该多播群组对应的数据。也包括UE2在切换后接收到的该多播群组对应的数据,即该UE2在目标小区中接收的该多播群组对应的数据。可以理解的是,切换前后UE2所接收的该多播群组的数据都称之为多播数据。
数据#1:UE2在源小区中时请求的数据。UPF或源接入网设备原本要发给UE2,但由于存在内容相同的多播数据的传输而未发送给UE2。UE2请求的数据可以是多播数据,也可以是单播数据,本申请对此不作限定。
应理解,多播数据和数据#1只是为了便于区分上述不同而定义,二者本质上是内容相同的数据。这里,内容相同可以是指用于承载多播数据的数据包和用于承载数据#1的数据包的净荷部分相同,也可以是指用于承载多播数据的数据包和用于承载数据#1的数据包的包头相同,净荷部分也相同。本申请对此不作限定。
第二,在本申请实施例中,数据可以承载在多个数据包中传输。例如,多播数据的数据包可以表示承载了该多播数据的数据包。接收设备(如终端设备)可以对接收到的对应于同一数据的多个数据包合并后,可以获取其中承载的数据。
在本申请实施例中,由于多播数据与数据#1是内容相同的数据,故接收设备(如终端设备)可以基于接收到的多播数据的数据包,获取其中承载的数据。由此获取到的数据为多播数据,或者也可以说是数据#1。
下文中在涉及数据#1的传输、发送和接收的描述,可以理解为对多播数据的数据包的传输、发送和接收。本领域的技术人员可以理解其含义。
第三,在本申请中,涉及网元A向网元B发送消息或数据包,以及网元B接收来自网元A的消息或数据包的相关描述,旨在说明该消息或数据包是要发给哪个网元,而并不限定它们之间是直接发送还是经由其他网元间接发送。
比如,文中所述的源接入网设备向目标接入网是设备发送消息或数据包,并不限定源接入网设备是直接向目标接入网设备发送消息或数据包。在N2切换场景下,由于源接入网设备与目标接入网设备之间不支持Xn接口的通信,故,源接入网设备与目标接入网设备之间的通信可以通过AMF来转发。而在Xn切换场景下,由于源接入网设备与目标接入网设备之间支持Xn接口的通信,故源接入网设备与目标接入网设备之间可以直接交互,而无需AMF的转发。文中虽未一一罗列,但本领域的技术人员可以理解其含义。
第四,在本申请中,“用于指示”可以包括用于直接指示和用于间接指示。当描述某一指示信息用于指示A时,可以包括该指示信息直接指示A或间接指示A,而并不代表该指示信息中一定携带有A。
将指示信息所指示的信息称为待指示信息,则具体实现过程中,对待指示信息进行指示的方式有很多种,例如但不限于,可以直接指示待指示信息,如待指示信息本身或者该待指示信息的索引等。也可以通过指示其他信息来间接指示待指示信息,其中该其他信息与待指示信息之间存在关联关系。还可以仅仅指示待指示信息的一部分,而待指示信息的其他部分则是已知的或者提前约定的。例如,还可以借助预先约定(例如协议规定)的各个信息的排列顺序来实现对特定信息的指示,从而在一定程度上降低指示开销。同时,还可以识别各个信息的通用部分并统一指示,以降低单独指示同样的信息而带来的指示开销。
待指示信息可以作为一个整体一起发送,也可以分成多个子信息分开发送,而且这些子信息的发送周期和/或发送时机可以相同,也可以不同。具体发送方法本申请不进行限定。
第五,在本申请实施例中,“当……时”、“在……的情况下”、“若”以及“如果”等描述均指在某种客观情况下设备(如,终端设备或者网络设备)会做出相应的处理,并非是限定时间,且也不要求设备(如,终端设备或者网络设备)在实现时一定要有判断的动作,也不意味着存在其它限定。
第六,在下文示出的实施例中第一、第二以及各种数字编号仅为描述方便进行的区分,并不用来限制本申请实施例的范围。例如,区分不同的多播数据、不同的UE、不同的PDU会话等。
第七,“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B的情况,其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a、b和c中的至少一项(个),可以表示:a,或,b,或,c,或,a和b,或,a和c,或,b和c,或,a、b和c。其中a、b和c分别可以是单个,也可以是多个。
第八,下文实施例所结合的多个附图中,源接入网(source RAN,S-RAN)可对应源接入网设备,目标接入网(target RAN,T-RAN)可对应目标接入网设备,AMF可对应接入和移动性管理网元,源AMF(source AMF,S-AMF)可对应源接入和移动性管理网元,SMF可对应会话管理网元,UPF可对应用户面网元。
第九,下文示出的多个实施例中,都是假设多播数据在UPF侧合并的情况下示出的。但这不应对本申请构成任何限定。基于相同的构思,本领域的技术人员在以下实施例所提供的方法的基础上做出相应的变化,即可实现多播多播场景下终端设备的切换。
第十,下文示出的多个实施例和附图中SMF网元可能为单播会话管理网元;也可能为针对多播会话(或者说,多播群组、多播数据等)的管理而使用的特定会话管理网元。若SMF为针对多播会话的管理而使用的特定会话管理网元,AMF与该SMF的交互可能会涉及其他流程,下文及附图中虽未予以示出,但本领域的技术人员应当理解,AMF与SMF的其他交互流程并不影响本申请各实施例的实施。还应理解,本申请对SMF是单播会话管理网元还是特定会话管理网元并不加以限定。还应理解,如果SMF为单播会话管理网元,其可以具备管理多播会话的能力(比如,向UPF和RAN发送配置信息等)。
当SMF是特定会话管理网元时,那么此处的UPF可以是特定的用户面网元,也可以是单播用户面网元。
下文多个实施例示出了两种不同的实现方式。在一种实现方式中,UE2在接收多播数据的同时由源接入网设备切换至目标接入网设备;在后一种实现方式中,UE2在源小区中由接收多播数据切换为接收单播数据后再切换至目标接入网设备。下文结合图4至图9描述的实施例示出了上述前一种实现方式下的具体流程,结合图10至图12描述的实施例示出了上述后一种实现方式下的具体流程。下面结合附图详细说明各实施例。
图4是本申请一实施例提供的切换方法400的示意性流程图。如图4所示,该方法400可以包括步骤401至419。下面对方法400中的各步骤做详细说明。
在步骤401中,源小区中属于同一多播群组中的各终端设备接收多播数据。
源小区中可能存在多个终端设备接收多播数据,该多个终端设备为同一多播群组中的终端设备。该多播群组是与该多播数据对应的多播群组。该多个终端设备例如可以包括但不限于驻留在源小区中的UE1和UE2。应理解,该多播群组还可以包括其他小区中的终端设备,本申请对此不作限定。
在一种实现方式中,源接入网设备可以预先通过RRC消息为源小区中的属于该多播群组的各终端设备分配G-RNTI。各终端设备可以基于接收到的G-RNTI接收来自源接入网设备的多播数据。
在另一种实现方式中,源接入网设备也可以预先通过RRC消息为源小区中的属于该多播群组的各终端设备分配各自的小区无线网络临时标识(cell-radio networktemporary identifier,C-RNTI)。源接入网设备可以将该多播数据单独地发给源小区中属于该多播群组中的各个终端设备。各终端设备可以基于C-RNTI接收该多播数据。
应理解,各终端设备基于G-RNTI接收多播数据的具体过程、基于C-RNTI接收多播数据的具体过程与基于C-RNTI接收单播数据的具体过程相似,为了简洁,这里不作详述。
在本申请实施例中,各终端设备可以基于已有的传输通道(如,PDU会话)来接收上述多播数据,也可以基于上述多播数据的传输创建传输通道,进而基于新创建的传输通道接收上述多播数据。
可选地,在步骤401之前,该方法还包括步骤402,源小区中的各终端设备创建多播传输通道。
在本申请实施例中,各终端设备创建的传输通道为用于传输多播数据的通道,具体可以为由UPF到源接入网设备的传输多播数据的通道。各终端设备创建的传输通道可用传输各终端设备请求的数据。例如,UE2的传输通道可用于传输UE2请求的数据。
示例性地,各终端设备创建的多播传输通道例如可以包括但不限于:多播专用PDU会话、多播专用隧道、多播专用QoS Flow、携带了承载多播数据的指示信息的单播QoS Flow或其他可用于传输多播数据的通道。各终端设备创建的可以是多播专用传输通道,例如可以包括但不限于:多播专用PDU会话、多播专用隧道、多播专用QoS Flow或其他可专门用于传输多播数据的通道。
该源小区中接收多播数据的终端设备例如可以包括但不限于上述UE1和UE2。UE1可基于多播数据创建多播传输通道1,UE2可基于多播数据创建多播传输通道2。可以理解,源小区中接收多播数据的各终端设备均可以基于多播数据创建自己的多播传输通道。下文中仅为便于理解和说明,假设源小区中接收多播数据的终端设备包括UE1和UE2,也就是说,UE1和UE2是属于同一多播群组的终端设备。
需要说明的是,各终端设备在向核心网发送请求时,可以请求多播数据。基于该请求,各终端设备可以各自为多播数据创建多播传输通道。
各终端设备创建多播传输通道的具体过程与现有技术中终端设备创建传输通道的具体过程相同。例如,各终端设备创建多播专用PDU会话的具体过程与现有技术中终端设备创建PDU会话的具体过程相同。为了简洁,这里不做详述。
由于该源小区中的多播群组中的各终端设备所创建的多播传输通道都是针对多播数据而创建的,因此UPF可以对多个多播传输通道中的多播数据进行合并。例如,第一种可能的实现方式,UPF可以通过UE1的多播传输通道1传输该多播数据,而将原本通过UE2的多播传输通道2传输的数据过滤,故UE2的多播传输通道2中未传输多播数据。第二种可能的实现方式,UPF也可以通过UE2的多播传输通道2传输多播数据,而将原本通过UE1的多播传输通道1传输的数据过滤,故UE1的多播传输通道1中未传输多播数据。第三种可能的实现方式,网络也可以针对该多播数据单独创建一个多播共享传输通道,该多播共享传输通道并非针对上述多播群组中的任意一个终端设备而创建。UPF可以通过该多播共享传输通道传输多播数据,而将原本通过UE1的多播传输通道1传输的数据过滤,并将原本通过UE2的多播传输通道2传输的数据过滤,故UE1的多播传输通道1中未传输多播数据,UE2的多播传输通道2中也未传输多播数据。应理解,UPF对多播数据进行合并仅为一种可能的实现方式。如前所述,源接入网设备也可以对多播数据进行合并,此情况下,UPF不对多播数据进行合并。由于前文结合图2和图3详细说明了二者的区别,为了简洁,这里不再赘述。
为方便说明,将多播数据的传输通道记为多播传输通道0。如前所述,在第一种实现方式中,多播传输通道0可以是上述多播传输通道1,而多播传输通道2为UE2的用于传输多播数据的通道;在第二种实现方式中,多播传输通道0可以是上述多播传输通道2,而多播传输通道1为UE1的用于传输多播数据的通道;在第三种实现方式中,多播传输通道0可以是单独创建的一个多播共享传输通道,而多播传输通道1为UE1的用于传输多播数据的通道,多播传输通道2为UE2的用于传输多播数据的通道。
应注意,即便UE1和UE2分别各自创建了多播专用PDU会话,若网络基于多播数据单独创建了多播共享传输通道,该多播共享传输通道也并不限于PDU会话,例如也可以是多播专用隧道、多播专用QoS Flow等。本申请对此不作限定。
在本实施例中,假设该多播数据未通过多播传输通道2传输。即,多播传输通道0可以是多播传输通道1,也可以是单独创建的一个多播共享传输通道。
在本申请实施例中,该源小区中属于同一多播群组的各终端设备分别对应的多播传输通道虽然并不是都真正传输了多播数据,但仍可以保证各多播传输通道数据包的序号信息的同步。
以UE1和UE2分别对应的多播传输通道1和多播传输通道2为例,多播传输通道1和多播传输通道2中的数据包的序号信息的同步可以表现为二者的数据包(例如GTP-U数据包)的序列号(sequence number)相同。这里,序列号可以理解为序号信息的一种。多播传输通道可以维护一个序列号,用来对自UPF发送的数据包进行计数。这可以通过UPF的配置来实现。
举例来说,假设UPF选择通过UE1的多播传输通道1传输多播数据,此情况下,多播传输通道0即多播传输通道1。当UPF更新UE1的多播传输通道1的序列号时,可以同步更新同一多播群组的其他终端设备的多播传输通道(如UE2的多播传输通道2)的序列号。示例性地,UPF在通过多播传输通道1传输多播数据时,可以通过序列号来对发送的数据包进行计数。例如UPF每通过该多播传输通道1传输一个数据包,其序列号加一。UPF在为多播传输通道1中的数据包计数的同时,也可以更新多播传输通道2的序列号,以使得多播传输通道2的序列号与多播传输通道1的序列号同步。
另一示例,假设网络针对该多播数据单独创建一个多播共享传输通道,此情况下,多播传输通道0是该多播共享传输通道,而非上述多播传输通道1。当UPF更新网络创建的多播传输通道0的序列号时,可以同步更新同一多播群组的其他终端设备的多播传输通道(如UE1的多播传输通道1和UE2的多播传输通道2)的序列号。示例性地,UPF在通过多播传输通道0传输多播数据时,可以通过序列号来对发送的数据包进行计数。例如UPF每通过该多播传输通道0传输一个数据包,其序列号加一。UPF在为多播传输通道0中的数据包计数的同时,也可以更新多播传输通道1和多播传输通道2的序列号,以使得多播传输通道1和多播传输通道2的序列号与多播传输通道0的序列号同步。
又一示例,UPF在更新多播传输通道0的序列号时,不会立即同步更新同一多播群组的多播传输通道(如多播传输通道1和多播传输通道2)的序列号,而基于具体的事件,触发进行多播传输通道1和多播传输通道2的序列号的更新。例如,当切换发生时,SMF配置UPF发送End Marker数据包,此时UPF可以将多播传输通道1和多播传输通道2更新为多播传输通道0的序列号。
值得注意的是,上述同步机制仅做示例,不应对本申请构成任何限定。
上述序列号例如可以参考现有的GTP-U序列号的机制来实现,或者,也可以通过新增一个GTP-U序列号来实现,又或者,可以通过在GTP-U数据包内部加入额外的序号信息实现,本申请对此不作限定。
在步骤403中,源接入网设备根据UE2上报的测量报告确定UE2需要切换。
各UE在源小区中都可以执行测量控制和上报。源接入网基于各UE上报的测量报告,确定是否满足切换条件,并在满足切换条件的情况下执行切换流程。源接入网设备基于测量报告确定是否满足切换条件的具体内容可以参考现有技术,为了简洁,这里不作详述。
在本实施例中,假设源接入网设备根据UE2上报的测量报告确定UE2需要切换。
在步骤404中,目标接入网设备获取第一消息,该第一消息用于请求为UE2切换至目标接入网设备建立资源。在目标接入网设备建立UE2相关的上下文信息,或者说,将UE2切换至目标接入网设备。
在本实施例中,该第一消息用于请求为UE2切换至目标接入网设备建立资源,可以包括,为UE2切换至目标接入网设备建立UE2相关的上下文信息UE2、PDU会话的上下文。
步骤404的一种实现方式是,源接入网设备可以基于Xn接口向目标接入网设备发送该第一消息。例如在Xn切换场景下,源接入网设备和目标接入网设备可以由同一AMF管理,或者,源接入网设备和目标接入网设备之间支持Xn接口的通信。在这种实现方式中,该第一消息例如可以是切换请求(Handover Request)消息。
步骤404的另一种可能的实现方式是,源接入网设备向核心网网元(例如AMF)发送切换要求(Handover Requied)消息,核心网网元可以基于该切换要求消息,向目标接入网设备发送第一消息。例如在N2切换场景下,源接入网设备和目标接入网设备之间不支持Xn接口的通信。在这种实现方式中,该第一消息例如也可以是切换请求(Handover Request)消息。
本申请对于第一消息的传输路径、步骤404的具体实现方式以及第一消息的具体信令名称均不作限定。
可选地,该第一消息中可以携带用于传输多播数据的信息。
这里,用于传输多播数据的信息具体可以包括多播数据的数据标识、多播群组的标识、多播会话的标识、多播PDU会话的标识、多播隧道的标识、多播数据的识别信息,或QFI等可用于识别多播数据(或者说,该多播数据所对应的多播群组)的信息。在上文中已经说明,SMF可以向RAN发送配置信息,该配置信息中可以包含多播数据与传输通道的映射关系。因此,目标接入网设备获取到多播会话的指示或传输通道的指示中的任意一项信息便可以识别出该多播会话。在该步骤404中,目标接入网设备还可以进一步从该第一消息中获取用于传输多播数据的信息。
当然,上述第一消息中也可以不携带用于传输多播数据的信息。源接入网设备可以通过其他信令向目标接入网设备发送用于传输多播数据的信息。目标接入网设备可以从源接入网设备分别获取到第一消息和用于传输多播数据的信息。本申请对于第一消息是否携带用于传输多播数据的信息并不作限定。
在步骤405中,目标接入网设备发送第二消息,该第二消息用于通知源接入网设备目标接入网设备上已建立的资源。
在本实施例中,目标接入网设备上已建立的资源包括为UE2切换到目标接入网设备而建立的资源。目标接入网设备在步骤404中接收到第一消息后,可以根据第一消息,建立UE2接入目标接入网设备的相关资源,例如包括UE2相关的上下文信息、PDU会话的上下文等。目标接入网设备可以发送第二消息,以将为UE2建立的资源通知给源接入网设备。
与步骤404相对应,步骤405的一种可能的实现方式是,目标接入网设备向源接入网设备发送该第二消息。例如在Xn切换场景下,目标接入网设备和源接入网设备可以由同一个AMF管理,或者,目标接入网设备和源接入网设备之间支持Xn接口的通信。在这种实现方式中,该第二消息例如可以是切换请求响应(Handover Request Response)消息。
步骤405的另一种可能的实现方式是,目标接入网设备可以向核心网网元(如AMF)发送该第二消息。核心网网元可以根据该第二消息,向源接入网合并发送切换命令(Handover Command)消息。例如在N2切换场景下,目标接入网设备和源接入网设备之间不支持Xn接口的通信。在这种实现方式中,该第二消息例如可以是切换请求确认(HandoverRequest Acknowledge)消息。
应理解,本申请对于第二消息的传输路径、步骤405的具体实现方式以及第二消息的具体信令名称均不作限定。
可选地,该第二消息中携带UE2接入目标接入网设备的相关信息。UE2接入目标接入网设备的相关信息例如可以包括接入网隧道信息(tunnel information),或者是GTP隧道信息(GTP tunnel)。该接入网隧道信息可用于指示用于转发多播数据的转发隧道的标识(forwarding tunnel ID),或者可以用于指示传输层的地址(transport layer address)以及GTP隧道端点标识(GTP-tunnel endpoint identifier,GTP-TEID)。在本实施例中,该转发隧道可用于源接入网设备向目标接入网设备转发多播数据。
在该步骤405中,源接入网设备还可以进一步从该第二消息中获取该接入网隧道信息。
当然,该第二消息中也可以不携带上述接入网隧道信息。目标接入网设备可以通过其他信令向源接入网设备发送该接入网隧道信息。源接入网设备可以从目标接入网设备分别获取到第二消息和接入网隧道信息。本申请对于第二消息是否携带接入网隧道信息并不作限定。
此外,该第二消息中还可以携带发给UE2的容器信息,例如包括目标接入网设备发送给UE2的RRC重配消息,例如包括该目标小区的小区标识、C-RNTI、G-RNTI、安全识别信息等中的一项或多项,以便于UE2切换至目标接入网设备。
上述步骤401至步骤405可以归为切换准备(handover preparation)阶段。
在步骤406中,UE2从源接入网设备切换至目标接入网设备。
UE2从源接入网设备切换至目标接入网设备也可以称为,UE2从源小区切换至目标小区。UE2从源接入网设备切换至目标接入网设备的完成可以理解为是空口切换的完成。完成了空口切换的UE2可以从目标接入网设备接收数据,而不再从源接入网设备直接接收数据。
UE2进行空口切换的具体过程可以参考现有技术,为了简洁,这里不做详述。
在步骤407中,源接入网设备通过转发隧道向目标接入网设备转发多播数据的数据包。相应地,目标接入网设备接收来自该源接入网设备的数据包。
虽然UE2切换至目标接入网设备,源接入网设备仍可以通过多播传输通道0从UPF接收多播数据,并向源小区中同一多播群组的其他UE(如上述UE1)发送该多播数据。
源接入网设备可以将在多播传输通道0中接收到的多播数据转发给目标接入网设备。为便于区分和说明,在本实施例中,将源接入网设备通过多播传输通道0从UPF接收到的多播数据的数据包记为第二数据包。因此,该目标接入网设备通过转发隧道从源接入网设备接收到的多播数据的数据包也为第二数据包,将后文中目标接入网设备从UPF接收而无需经由源接入网设备转发的多播数据的数据包记为第一数据包。
另一方面,UE2切换到目标接入网设备后,目标接入网设备可以进一步向核心网发送消息,以完成核心网侧传输路径的切换。
在步骤408中,目标接入网设备向AMF发送N2消息,该N2消息用于通知UE2的空口切换已完成。相应地,在步骤408中,AMF接收来自目标接入网设备的N2消息。
该N2消息可以是路径切换请求(path switch request)消息,也可以是切换通知(handover nodify)消息。这取决于该目标接入网设备和源接入网设备之间是通过Xn接口还是通过N2接口进行切换的。例如,若目标接入网设备和源接入网设备为同一个AMF下的接入网设备,或者,目标接入网设备和源接入网设备之间当前支持Xn接口的传输,则该切换为基于Xn接口的切换(Xn-based handover),该N2消息可以是路径切换请求消息。若目标接入网设备和源接入网设备为不同AMF下的接入网设备,或者目标接入网设备和源接入网设备之间当前仅支持N2接口的信令传输,则该切换为基于N2接口的切换(N2-based handover),该N2消息可以是切换通知消息。
应理解,上文对N2消息的列举仅为示例,不应对本申请构成任何限定。本申请对于该N2消息的具体名称不作限定。
可选地,该N2消息中包含在目标接入网设备建立的传输通道(例如PDU会话等)的列表以及对应的会话中成功建立的QoS flow的列表信息。
在步骤409中,AMF向SMF发送第三消息,该第三消息用于指示上述用于传输多播数据的信息。相应地,在步骤409中,SMF接收来自AMF的第三消息。
AMF可以通过第三消息请求SMF配置UE2的多播传输通道2上的数据的传输。该多播传输通道2可用于传输UE2请求的数据,即数据#1。而数据#1对应于上述用于传输多播数据的信息,也即与上述多播数据是内容相同的数据,故也可以认为该第三消息是用于请求SMF配置多播数据的传输。
该第三消息可以是N11消息。
在一种可能的设计中,该第三消息可以是Nsmf接口PDU会话更新会话管理上下文请求(Nsmf_PDUSession_UpdateSMContext Request)消息。
可选地,该第三消息中携带以下一项或多项:传输通道(例如PDU会话等)的标识信息、会话管理(session managemenet,SM)上下文的标识信息、N2 SM信息。其中,N2 SM信息中包含了成功建立的QoS flow的列表信息,或者建立失败的QoS flow的列表信息。
由此,SMF可以根据第三消息,获取多播上下文信息。一种示例中,SMF本地存储了多播上下文信息与单播信息的对应关系。下表示出了多播上下文信息与单播信息的对应关系。应理解,下表仅为便于理解而示例,不应对本申请构成任何限定。上述对应关系也并不一定以表格的形式存在。
基于上述多播上下文信息,SMF可以确定上述用于传输多播数据的信息。
在前文中已经说明,在传输多播数据之前,SMF就已经预先生成了配置信息,该配置信息中包含多播数据与传输通道的映射关系。因此,当SMF在步骤408中接收到来自AMF的用于传输多播数据的信息时,便可以基于此确定UE2在源小区中接收的数据为多播数据以及该多播数据对应的多播群组、多播会话、数据标识、传输通道这些信息中的一个或多个。
在步骤410中,SMF向UPF发送第四消息,该第四消息用于请求配置UE2的多播传输通道2上的数据的传输。相应地,在步骤410中,UPF接收来自SMF的第四消息。
该第四消息可以是N4消息。
SMF可以通过第四消息指示UPF对UE2请求的数据#1的转发行为。在本实施例中,UE2请求的数据#1的数据包即上述第一数据包。即,该SMF可以通过第四消息指示对第一数据包的转发行为。
可选地,该第四消息中包括以下一项或多项:针对第一数据包的转发行为的指示、用于传输多播数据的信息、识别规则、转发行为规则。
在一种实现方式中,SMF可以将针对第一数据包的转发行为的指示通过N4消息发送给UPF。
其中,可以理解的是,接入网设备从UPF接收的第一数据包和上述的UE2在源小区中时请求的数据#1内容相同。在该UE2切换到目标接入网设备前,该数据#1原本要发送给UE2,但由于存在内容相同的多播数据的传输而被过滤。在该UE2切换到目标接入网设备后,SMF可以确定针对该数据#1的转发行为(即第一数据包的转发行为)的指示。针对该数据#1的转发行为的指示具体可以包括:是否继续过滤该数据#1;并可以在不过滤的情况下,进一步确定将该数据#1映射到哪个传输通道上。
具体地,SMF可以根据UE2所请求的数据#1的识别信息,确定该UE2属于多播数据所对应的多播群组。SMF可以基于UE2切换至目标接入网设备,确定对该UE2所请求的数据#1不再进行过滤,并可进一步根据预先确定的多播数据与传输通道的映射关系,确定将该数据#1映射到哪个传输通道上传输。
或者,SMF可以根据UE2所请求的数据#1的识别信息,确定在目标小区中是否存在内容相同的多播数据的传输。在目标小区中存在多播数据传输的情况下,SMF可以确定继续过滤该数据#1。SMF可以直接向UPF指示对数据#1的转发行为规则(即第一数据包的转发行为规则)为过滤该数据#1。在目标小区不存在多播数据传输的情况下,SMF可以确定不对该数据#1进行过滤,并可进一步根据预先确定的多播数据与传输通道的映射关系,确定将该数据#1映射到哪个传输通道上传输。
应理解,上述对数据#1的说明是为了具体解释UE2所请求的数据在UE2切换至目标接入网设备前后的处理。为作区分,下述将UE2切换至目标接入网设备后目标接入网设备从UPF接收的数据包仍称为第一数据包。
在另一种实现方式中,该SMF可以将用于传输多播数据的信息、识别规则以及转发行为规则通过N4消息发送给UPF。
SMF也可以直接将识别规则和转发行为规则发送给UPF,由UPF基于识别规则来识别接收到的多播数据对应于哪个多播群组,并基于转发行为规则确定是否对数据#1进行转发以及在哪个通道上转发。
关于识别规则和转发行为规则的具体内容在上文中已经做了详细说明,为了简洁,这里不再赘述。
在本实施例中,UPF也可以根据预先从SMF接收到的配置信息,确定对第一数据包的转发行为规则。
由于UPF从SMF接收到的配置信息中包含了多播数据和传输通道的映射关系。当UPF接收到第一数据包时,UPF首先可以根据数据#1的识别信息,确定该UE2属于多播数据所对应的多播群组。UPF可以基于UE2切换至目标接入网设备,确定对该UE2所请求的数据#1不再进行过滤,并可进一步根据SMF发送的多播数据与传输通道的映射关系,确定将该数据#1映射到哪个传输通道上传输。
或者,UPF可以基于识别规则判断目标小区中是否存在与该数据#1内容相同的多播数据内容的传输。在存在与数据#1内容相同的多播数据的情况下,UPF可以确定对该数据#1进行过滤;在不存在与该数据#1内容相同的多播数据的情况下,UPF可以确定对该数据#1不进行过滤,并可进一步根据转发行为规则中,确定将该数据#1映射到哪个传输通道上传输。
进一步可选地,该N4消息中还包括End Marker数据包的相关信息。
End Marker数据包的相关信息例如可以包括:携带多播传输通道2的标识信息的End Marker数据包或指示创建该End Marker数据包的信息。
之所以在该End Marker数据包中携带多播传输通道2的标识信息,是因为多播传输通道2与转发隧道间具有对应关系。由于源接入网设备与目标接入网设备之间可能存在多个转发隧道,该多个转发隧道可用于发送不同终端设备的数据,比如除了UE2之外的其他终端设备的数据;还可用于发送同一终端设备在不同传输通道(如不同PDU会话)中的数据。各转发隧道可以与与各终端设备的多播传输通道对应。为了便于源接入网设备在接收到该End Marker数据包时,确定通过哪个转发隧道向目标接入网设备发送该End Marker数据包,该End Marker数据包中可以携带多播传输通道2的标识信息,以便于源接入网设备根据该多播传输通道2的标识信息确定与之对应的转发隧道。从而可以避免在错误的转发隧道发送该End Marker数据包,对其他UE的转发隧道或UE2的其他转发隧道中的数据传输造成影响。
在本申请实施例中,SMF可以自行生成该End Marker数据包,也可以指示UPF生成该End Marker数据包。若SMF指示UPF生成该End Marker数据包,则可以将多播传输通道2的标识信息指示给UPF。
该多播传输通道2的标识信息例如可以是多播专用PDU会话2的标识信息、多播专用隧道的标识信息、多播专用QoS Flow的QFI或携带了传输多播数据的指示信息的单播QoSFlow的QFI,等,本申请对此不作限定。
该多播传输通道2的标识信息还可作为用于指示传输End Marker数据包的传输通道的信息,UPF可基于该多播传输通道2的标识信息,在多播传输通道2中传输End Marker数据包。
该多播传输通道2的标识信息也可以不作为用于指示传输End Marker数据包的传输通道的信息,例如UPF可以通过PDU会话1或PDU会话2中的任意一个发送End Marker数据包。本申请对此不作限定。
上述传输通道2的标识信息的具体作用可预先定义,例如在协议中定义,本申请对此不作限定。
在步骤411中,UPF向源接入网设备发送第二End Marker数据包。相应地,在步骤411中,源接入网设备接收来自UPF的第二End Marker数据包。
在步骤412中,源接入网设备向目标接入网设备发送第一End Marker数据包。
为了便于区分和理解,这里将源接入网设备向目标接入网设备发送的End Marker数据包记为第一End Marker数据包,将UPF向源接入网设备发送的End Marker数据包记为第二End Marker数据包。如前所述,UPF可以基于SMF的指示,通过多播传输通道2发送第二End Marker数据包。
如,多播传输通道可以是多播专用PDU会话。此情况下,源接入网设备可以将在PDU会话2中接收到的第二End Marker数据包直接转发给目标接入网设备。也即,该第二EndMarker数据包和第一End Marker数据包可以是相同的数据包。源接入网设备可以直接根据传输该第二End Marker数据包的传输通道来确定该第二End Marker数据包是针对哪个传输通道中的数据发送的。从而可以基于与多播传输通道2对应的转发隧道向目标接入网设备发送第一End Marker数据包。又如,多播传输通道也可以是更小粒度的通道,如多播专用隧道、多播专用QoS Flow、单播QoS Flow等。由于End Marker数据包是基于PDU会话的粒度而发送的,因此当多播传输通道是小于PDU会话粒度的通道时,源接入网设备可能并不一定会将从UPF接收到的针对该多播数据的第二End Marker数据包直接转发给目标接入网设备,而是将该多播传输通道所属PDU会话中接收到的针对单播数据的EndMarker数据包(例如记为第三End Marker数据包)发送给目标接入网设备,以指示目标接入网设备,源接入网设备停止向目标接入网设备转发数据。此情况下,第二End Marker数据包与第一EndMarker数据包是不同的数据包。比如,该412步骤中的第一End Marker数据包可以是上述第三End Marker数据包。
需注意,源接入网设备如果将该多播传输通道所属PDU会话中接收到的针对单播数据的第三End Marker数据包发送给目标接入网设备,则该源接入网设备可以等待针对该PDU会话中各传输通道的数据的End Marker数据包(如上述第二End Marker数据包和第三End Marker数据包)都到达后,再将该第三End Marker数据包发送给目标接入网设备。
当然,源接入网设备也可以在针对该多播传输通道所属PDU会话中各传输通道的数据的End Marker数据包都到达后,自行生成第一End Marker数据包发送给目标接入网设备。本申请对此不作限定。
由于此情况下,源接入网设备发送给目标接入网设备的第一End Marker数据包是针对单播数据的End Marker数据包,因此目标接入网设备可以参照已有技术中的方法来处理该第一End Marker数据包。
在本实施例中,UPF也可以自行决定通过多播传输通道0或多播传输通道2来传输第二End Marker数据包。由于该第二End Marker数据包中携带多播传输通道2的标识信息,源接入网设备可以基于该多播传输通道2的标识信息,通过与之对应的转发隧道向目标接入网设备发送该End Marker数据包。
在某些可能的设计中,当UPF通过多播传输通道2发送第二End Marker数据包时,该第二End Marker数据包的包头中携带了多播传输通道2的标识信息,因此,也可以认为该第二End Marker数据包中携带了多播传输通道2的标识信息。或者,该第二End Marker数据包的净荷(payload)部分也可以携带多播传输通道2的标识信息,本申请对此不作限定。而当UPF通过多播传输通道0发送第二End Marker数据包时,该第二End Marker数据包的包头中携带了多播传输通道2的标识信息,上述多播传输通道2的标识信息可以通过该第二EndMarker数据包的净荷部分来携带。
由于源接入网设备接收第二数据包的通道和接收来自UPF的第二End Marker数据包的通道并非同一个,可能使得源接入网设备发送给目标接入网设备的第一End Marker数据包和多播数据的数据包(如第二数据包)不同步,例如序列号在后的第一End Marker数据包先到达目标接入网设备,序列号在前的第二数据包后到达目标接入网设备,从而导致乱序或丢包。因此可以通过序列号的方式,保证目标接入网设备接收到多播数据的数据包不乱序、不丢包。
为便于理解和说明,这里将第二数据包中包括的该第二数据包所对应的序列号记作第一序列号。将上述第一End Marker数据包中包括的该第一End Marker数据包所对应的序列号记作第二序列号。
可以理解,该第一End Marker数据包和第二数据包都可经由源接入网设备与目标接入网设备之间的转发隧道发送至目标接入网设备。目标接入网设备可以基于数据包的序列号之间的大小关系,确定是否转发该第二数据包,也即可以是否执行步骤413,目标接入网设备向UE2发送第二数据包。
在本实施例中,若第一序列号小于第二序列号,则目标接入网设备可以向终端设备发送该第二数据包。换言之,只要目标接入网设备从源接入网设备接收到的数据包的序列号小于第一End Marker数据包的序列号,目标接入网设备便可将从源接入网设备接收到的数据包转发给UE2。若第一序列号大于或等于第二序列号,则目标接入网设备可将从UPF接收的第一数据包发送给UE2,即执行步骤415。
下面结合具体的例子来说明源接入网设备和目标接入网设备在接收到第二数据包、第一End Marker数据包时的处理逻辑。
例如,UPF最近一次通过多播传输通道0发送多播数据的数据包的序列号为20(即,第一序列号的一例),则UPF可以通过多播传输通道2发送序列号为21(即,第二序列号的一例)的第一End Marker数据包。源接入网设备可以将该序列号为20的数据包和序列号为21的第一End Marker数据包转发给目标接入网设备。目标接入网设备在接收到序列号为21的第一End Marker数据包之后,会开始考虑发送来自UPF并且不经过源接入网设备转发的数据。换言之,目标接入网设备只需要将从源接入网设备接收到的序列号为20及之前的数据包(例如包括序列号小于或等于20的数据包)发送给终端设备。而针对序列号为21的数据包(例如包括序列号大于21的数据包),目标接入网设备可以不从源接入网设备接收。
另一种可能性是,源接入网设备在接收到序列号为21的第一End Marker数据包之后,便可以对序列号为21之后的数据包(例如包括序列号大于或等于22的数据包)不作转发。换言之,源接入网设备只需要将多播传输通道0中接收到的序列号为20及之前的数据包(例如包括序列号小于或等于20的数据包)转发给目标接入网设备。
当然,目标接入网设备也在第一End Marker数据包的序列号与从源接入网设备接收到的数据包的序列号相同的情况下,停止从源接入网设备接收多播数据的数据包,或者,源接入网设备不再向目标接入网设备转发该多播数据的数据包。为了简洁,这里不再举例说明。在步骤413中,目标接入网设备向UE2发送从源接入网设备接收到的第二数据包。
目标接入网设备可以基于上文所述的对第一序列号和第二序列号的大小关系来确定是否向UE2转发该第二数据包。从而可以避免UE2对多播数据的丢包的发生,保证多播数据的完整接收。
在步骤414中,UPF向目标接入网设备发送第一数据包。相应地,在步骤414中,目标接入网设备接收来自UPF的第一数据包。
在一种实现方式中,UPF在执行完步骤411中第二End Marker数据包的发送之后,便可以通过与目标接入网设备间的下行用户连接发送第一数据包。该UPF与目标接入网设备之间的下行用户连接也即UE2切换后的多播传输通道2。UPF可以通过切换后的多播传输通道2(以下称之为多播传输通道2’)向目标接入网设备发送第一数据包。由于该多播传输通道2为基于多播数据而创建的多播传输通道,故该第一数据包传输在多播传输通道2’中。
由于多播传输通道0和多播传输通道2’中数据包的序列号是同步的,UPF可以通过序列号来隐式地指示各数据包的先后顺序,不会造成数据包的丢失。
在步骤415中,目标接入网设备向UE2发送第一数据包。
若第一序列号大于或等于第二序列号,目标接入网设备可以向UE2发送第一数据包。换言之,如果目标接入网设备从源接入网设备接收到的数据包的序列号大于或等于第一End Marker数据包的序列号,目标接入网设备可以开始考虑将从UPF接收到的数据包转发给UE2,而不再向UE2转发从源接入网设备接收到的数据包。
可选地,若第一序列号大于或等于第二序列号,该目标接入网设备停止接收来自源接入网设备数据包;或者,向源接入网设备发送第一指示,该第一指示用于指示源接入网设备停止发送多播数据;或者,通知源接入网设备不再从源接入网设备接收多播数据。
此后,目标接入网设备可以执行步骤415,将从UPF接收到的第一数据包发送给UE2。因此,第一数据包所对应的序列号(例如记作第三序列号)可以大于或等于第二序列号。
也就是说,目标接入网设备可以一直执行上述步骤413,直到第一序列号大于或等于第二序列号,目标接入网设备此后可以执行步骤415。当然,目标接入网设备也可能跳过步骤413,直接执行步骤415。比如在第一序列号大于或等于第二序列号的情况下。
下面结合具体的例子来说明目标接入网设备在接收到来自源接入网设备的第二数据包、第一End Marker数据包和第一数据包时的处理逻辑。比如,UPF通过多播传输通道0发送的序列号为19、20(即,第一序列号的两例)的数据包还未到达源接入网设备,但UPF通过多播传输通道2发送的序列号为21(即,第二序列号的一例)的End Marker数据包已经到达源接入网设备。目标接入网可能先接收到序列号为21的End Marker数据包,再接收到序列号为19、20的数据包。由于序列号20小于21,则目标接入网设备可以继续向UE2发送来自源接入网设备的数据包,直到将序列号20的数据包发送完。此后,目标接入网设备不再通过该转发隧道从源接入网设备接收数据包。可选地,目标接入网设备可以就此释放与源接入网设备之间的转发隧道,或者,也可以在后续步骤419发送资源释放请求消息之后,释放与源接入网设备之间的转发隧道。本申请对此不作限定。
另一方面,由于UPF通过多播传输通道2发送完序列号为21的End Marker数据包之后可能进一步通过多播传输通道2’发送第一数据包。UPF通过多播传输通道2’发送的第一数据包可以从序列号22(即,第三序列号的一例)开始发送,也可以从序列号22之前(即,第三序列号的又一例)的数据包开始发送,本申请对此不作限定。目标接入网设备可以先将从多播传输通道2’接收到的数据包缓存在本地,待到完成了序列号为20的数据包的发送后,从序列号22的数据包开始继续发送。
也就是说,目标接入网设备一方面可以将来自多播传输通道2’中的数据包缓存在本地,另一方面可以将来自源接入网设备的来自多播传输通道0中的数据包转发给UE2。直到来自多播传输通道0中的数据包的序列号大于或等于第一End Marker数据包的序列号,目标接入网设备可以停止对来自源接入网设备的数据包(也即多播数据的数据包)的转发,继而将来自多播传输通道2’中的数据包(也即第一数据包)发送给UE2。此后,目标接入网设备向UE2发送的数据包是从多播传输通道2’中接收到的数据包。
可以理解,上述多播传输通道2’和源接入网设备与目标接入网设备之间的转发隧道可以是同一PDU会话的直接转发路径(direct forwarding path)和间接转发路径(indirect forwarding path),也可以是两个不同的专用的传输隧道,此处不予限定。
在另一种实现方式中,UPF也可以通过多播传输通道0发送第二End Marker数据包。因此,UPF在接收到来自SMF的N4消息后,便可以通过与目标接入网设备的下行用户连接传输数据。也就是说,该步骤414并不一定在步骤413之后执行,也可以在步骤410之后执行。
在这种实现方式中,目标接入网设备接收到的数据包也可能会发生乱序。目标接入网设备仍然可以根据接收到的数据包的序列号来确定是继续向UE2发送来自源接入网设备的第二数据包,还是向UE2发送在多播传输通道2’中接收到的第一数据包。具体内容可参考上文描述,为了简洁,这里不再赘述。
应理解,上文所述两种实现方式中对步骤411至步骤414的执行顺序略有不同,但这仅为不同的实现方式,不应对本申请构成任何限定。
在步骤416中,UPF向SMF发送N4消息,该N4消息可理解为是对步骤411中的第四消息的响应,可用于指示UE2的多播传输通道上的数据传输的配置完成。相应地,在步骤416中,SMF接收来自UPF的N4消息。
在步骤417中,SMF向AMF发送N11消息,该N11消息可理解为是对步骤410中的第三消息的响应,可用于指示路径切换完成。相应地,在步骤417中,AMF接收来自SMF的N11消息。
与步骤410对应,该N11消息可以是Nsmf接口PDU会话更新会话管理上下文响应(Nsmf_PDUSession_UpdateSMContext Response)消息。
在步骤418中,AMF可以向目标接入网设备发送N2消息,该N2消息可以理解为是对步骤408中的N2消息的响应,可用于指示路径切换完成。相应地,在步骤418中,目标接入网设备接收来自AMF的N2消息。
与步骤408对应,该N2消息可以是路径切换响应(path switch response)消息。
应理解,步骤418可以是Xn切换场景下执行的步骤。在N2切换场景下,该步骤418并不一定执行。
在步骤419中,目标接入网设备向源接入网设备发送资源释放请求消息,以请求释放UE2的上下文。相应地,在步骤419中,源接入网设备接收来自目标接入网设备的资源释放请求消息。
在本实施例中,UE2的上下文例如可以转发隧道的资源。因此释放UE2的上下文可以包括释放转发隧道的资源。
应理解,步骤419可以是Xn切换场景下执行的步骤。在N2切换场景下,该步骤419并不一定执行。
由此,目标接入网设备与源接入网设备间的转发隧道得以释放。
基于上文所述的方法,UE2在接收多播数据的同时完成了切换。源接入网设备在向目标接入网设备请求切换的同时,将用于传输多播数据的信息发送给目标接入网设备,以便于目标接入网设备基于该信息向UE2转发该多播数据,并在路径切换后向UE2发送该多播数据或者与该多播数据内容相同的数据,从而可以避免对多播数据的数据包的丢失,有利于获得完整的数据。保证了UE2在多播数据的接收过程中无延迟的切换,同时保证了数据传输性能。
为了更好地理解本实施例,下面结合图5所示的例子来说明上述方法400。图5所示的示例中,传输通道为PDU会话,其中,传输通道0的具体形式可以是UE1的PDU会话1,传输通道2的具体形式可以是UE2的PDU会话2。
如图5所示,在图5的a)中,UE1和UE2均为驻留在源小区中的终端设备。此时,PDU会话1和PDU会话2均为建立在源接入网设备与UPF之间的传输通道。UPF可以通过UE1的PDU会话1向源接入网设备发送多播数据。源接入网设备将接收到的多播数据发送给源小区中与该多播数据对应的多播群组中的终端设备,比如包括上述UE1和UE2。
在本实施例中,PDU会话1的序列号与PDU会话2的序列号可以同步。比如,UPF在更新PDU会话1的序列号时,可以同步更新PDU会话2的序列号。
在图5的b)中,UE2由源接入网设备切换至目标接入网设备,或者说,由源小区切换到目标小区。源接入网设备可以将PDU会话1中接收到的多播数据的数据包(例如上述第二数据包)通过源接入网设备与目标接入网设备之间的转发隧道转发给目标接入网设备。目标接入网设备继而将从转发隧道接收到的第二数据包发送给UE2。
在图5的c)中,UPF可以在PDU会话2中发送针对多播数据的End Marker数据包1,并可并行地在PDU会话1中发送多播数据的数据包。源接入网设备从PDU会话2中接收到该EndMarker数据包1后,便可与从PDU会话1中接收到的多播数据的数据包一起发送给目标接入网设备。目标接入网设备可以将从源接入网设备接收到的多播数据的数据包继续发送给UE2,直到该End Marker数据包的序列号小于多播数据的数据包的序列号,目标接入网设备可以停止从源接入网设备接收该多播数据的数据包。
在图5的d)中,不同于a)、b)、c)中所示,PDU会话2的传输路径发生了改变,不再是建立在UPF和源接入网设备之间的传输通道,而是建立在UPF和目标接入网设备之间的传输通道。UPF可以通过PDU会话2向目标接入网设备发送数据#1的数据包(例如上述第一数据包)。
在图5的e)中,源接入网设备与目标接入网设备之间的转发隧道已被释放。目标接入网设备将接收到的数据#1的数据包发送给UE2。
由此,UE2在切换到目标接入网设备的同时,仍然可以保证对多播数据的完整接收。
图6是本申请另一实施例提供的切换方法600的示意性流程图。如图6所示,该方法600可以包括步骤601至步骤619。下面对方法600中的各步骤做详细说明。
在步骤601中,源小区中属于同一多播群组的各终端设备接收多播数据。
应理解,步骤601的具体过程与上文方法400中的步骤401的具体过程相同,为了简洁,这里不再重复。
在本申请实施例中,各终端设备可以通过已有的传输通道(如,PDU会话)来接收上述多播数据,也可以基于上述多播数据的传输创建传输通道,进而基于新创建的传输通道接收上述多播数据。
可选地,在步骤601之前,该方法600还包括:源小区中的各终端设备创建传输通道。
在本申请实施例中,该传输通道为用于传输多播数据的由UPF到源接入网设备的传输通道。各终端设备创建的传输通道可用于传输各终端设备请求的数据。例如,UE2的传输通道可用于传输UE2请求的数据。
示例性地,传输通道例如可以包括但不限于:PDU会话、隧道、QoS Flow或其他可用于传输数据的通道。
该源小区中的终端设备例如可以包括但不限于UE1和UE2。各终端设备可以各自创建传输通道,以便传输数据。例如,UE1可以创建传输通道1,UE2可以创建传输通道2。各终端设备创建传输通道的具体过程可以参考现有技术,为了简洁,这里不做详述。
在本实施例中,传输通道1可以是单播传输通道,也可以是多播传输通道。与之相似,传输通道2可以是单播传输通道,也可以是多播传输通道。本申请对此不做限定。
假设该源小区中的UE1和UE2请求的数据内容相同,因此UPF可以对传输通道1和传输通道2中内容相同的数据进行合并,通过多播的方式来向源小区中的UE1和UE2发送该数据。该UE1和UE2属于同一个多播群组。UPF通过多播的方式为该多播群组发送数据。该多播群组对应的数据可以称为多播数据。
应理解,本实施例中仅为便于理解和说明,假设源小区中接收多播数据的终端设备包括UE1和UE2,但这不应对本申请构成任何限定。接收多播数据的终端设备可以包括更多数量的终端设备,例如还可以包括源小区中的其他终端设备和/或其他小区中的终端设备。本申请对该多播群组中终端设备的数量不作限定。
在本实施例中,对于源小区中接收多播数据的终端设备来说,该多播数据可以通过UE1或UE2中任一个的传输通道来传输,或者,该多播数据可以通过网络建立的专门用于传输此多播数据的多播共享传输通道来传输。
为便于说明,本实施例中假设传输该多播数据的传输通道为传输通道0。该传输通道0例如可以是UE1的传输通道1,也可以是上述单独建立的多播共享传输通道。
作为一个示例,该多播数据可以承载在某一PDU会话的一个隧道中的一个QoSFlow上。
该PDU会话例如可以是UE1的PDU会话,也可以是单独为该多播数据建立的多播专用PDU会话。本申请对此不作限定。
可选地,该PDU会话是多播专用PDU会话;该PDU会话可以是基于多播数据创建的PDU会话;上述隧道是基于多播数据创建的隧道,上述QoS Flow可以是专用于承载多播数据的QoS Flow。
可选地,该PDU会话是单播PDU会话;上述隧道是多播专用隧道。该隧道可以是基于多播数据创建的多播专用隧道;上述QoS Flow可以是专用于承载多播数据的QoS Flow,也可以是用于承载单播数据的QoS Flow,但携带了指示信息,该指示信息用于指示该QoSFlow中承载了多播数据。
可选地,该PDU会话是单播PDU会话;上述隧道是单播隧道,上述QoS Flow是专用于承载多播数据的QoS Flow。
可选地,该PDU会话是单播PDU会话;上述隧道是单播隧道,上述QoS Flow是用于承载单播数据的QoS Flow,但携带了指示信息,该指示信息用于指示该QoS Flow中承载了多播数据。
由于UPF通过多播的方式通过传输通道0发送与数据#1内容相同的多播数据,传输通道2中并未传输该UE2请求的数据(例如记为数据#1),也未传输多播数据。
图中虽未示出,但可以理解,由于UE2还可以并行地接收其他数据,如其他单播数据和/或多播数据,故该传输通道2中也可以传输除数据#1和多播数据之外的其他数据。本申请对此不作限定。
UE2通过传输通道2接收其他数据的具体过程可以与现有技术相同,为了简洁,这里不作详述。
在步骤603中,源接入网设备根据UE2上报的测量报告确定UE2需要切换。
在步骤604中,源接入网设备向目标接入网设备发送第一消息,该第一消息用于请求为UE2切换至目标接入网设备建立资源。相应地,在步骤604中,目标接入网设备接收来自源接入网设备的第一消息。
可选地,该第一消息中携带用于传输多播数据的信息。这里,用于传输多播数据的信息具体可以包括:多播数据的数据标识、多播群组的标识、多播会话的标识、多播PDU会话的标识、多播隧道的标识、多播数据的识别信息,或QFI等可用于识别多播数据(或者说,该多播数据所对应的多播群组)的信息。上文方法400中对用于传输多播数据的信息做了详细说明,为了简洁,这里不再重复。
在步骤605中,目标接入网设备向源接入网设备发送第二消息,该第二消息用于指示目标接入网设备上建立的资源。相应地,在步骤605中,源接入网设备接收来自目标接入网设备的第二消息。
在本实施例中,目标接入网设备上已建立的资源包括为UE2切换到目标接入网设备而建立的资源。
可选地,该UE2接入目标接入网设备的相关信息包括接入网隧道信息,该接入网隧道信息可用于指示用于转发多播数据的转发隧道的标识,或者可以用于指示传输层的地址(transport layer address)以及GTP隧道端点标识(GTP-tunnel endpoint identifier,GTP-TEID)。在本实施例中,该转发隧道可用于源接入网设备向目标接入网设备转发多播数据。
在步骤606中,UE2从源接入网设备切换至目标接入网设备。
在步骤607中,源接入网设备通过转发隧道向目标接入网设备转发多播数据的数据包。相应地,在步骤607中,目标接入网设备通过转发隧道接收来自源接入网设备的数据包。
应理解,在本实施例中,源接入网设备可以从传输通道0中接收该多播数据,因此,源接入网设备通过转发隧道向目标接入网设备转发的多播数据的数据包也即通过传输通道0接收到的数据包。与方法400相似,源接入网设备从传输通道0接收到的多播数据的数据包可以记为第二数据包,该目标接入网设备通过转发隧道接收到的来自源接入网设备的多播数据的数据包也为第二数据包。
可选地,在步骤608中,目标接入网设备可以向UE2发送从源接入网设备接收到的第二数据包。相应地,在步骤608中,UE2接收来自目标接入网设备的第二数据包。
在步骤609中,目标接入网设备向AMF发送N2消息,该N2消息用于通知UE2的空口切换已完成。相应地,在步骤609中,AMF接收来自目标接入网设备的N2消息。
在步骤610中,AMF向SMF发送第三消息,该第三消息用于指示上述用于传输多播数据的信息。相应地,在步骤610中,SMF接收来自AMF的第三消息。
AMF可以通过第三消息请求SMF配置UE2的传输通道2上的数据的传输。该传输通道2可用于传输UE2请求的数据,即数据#1。而数据#1对应于上述用于传输多播数据的信息,也即与上述多播数据是内容相同的数据,故也可以认为该第三消息是用于请求SMF配置多播数据的传输。
该第三消息可以是N11消息。
应理解,步骤602至步骤607以及步骤609至步骤610的具体过程与上文方法400中的步骤402至步骤409的具体过程相同,可参考上文中步骤402至步骤409的相关描述,为了简洁,这里不再重复。
在步骤611中,SMF向UPF发送第四消息,该第四消息用于配置多播数据的传输。相应地,在步骤611中,UPF接收来自SMF的第四消息。
该第四消息可以是N4消息。
在本实施例中,可选地,该第四消息中可以包括以下一项或多项:针对数据#1的转发行为的指示、用于传输多播数据的信息、识别规则、转发行为规则,以及结束标记(EndMarker)数据包的相关信息。
其中,针对数据#1的转发行为规则的指示、用于传输多播数据的信息、对数据#1的转发规则的具体内容可参考上文方法400中的步骤410中的相关描述,为了简洁,这里不再重复。
在本实施例中,End Marker数据包可以包括针对传输通道0中传输的多播数据而创建的End Marker数据包,还可以包括针对传输通道2中传输的其他数据而创建EndMarker数据包。为便于区分,将针对多播数据创建的End Marker数据包记为End Marker数据包1,将针对传输通道2中传输的其他数据而创建的End Marker数据包记为End Marker数据包2。若传输通道2中传输的其他数据包括单播数据,则针对传输通道2中的单播数据创建End Marker数据包2的具体过程为现有技术,为了简洁,这里不做详述。若传输通道2中传输的其他数据包括多播数据,则针对传输通道2中的多播数据创建End Marker数据包2的具体过程与本实施例中针对多播数据创建End Marker数据包1的具体过程相同,可以参考本实施例流程来实现。可以理解,当传输通道2中传输的其他数据既包括单播数据有包括多播数据时,针对传输通道2中传输的其他数据而创建的End Marker数据包2可以为多个。本申请对此不作限定。
在本实施例中,上述End Marker数据包的相关信息具体可以是指End Marker数据包1的相关信息。该End Marker数据包1的相关信息例如可以包括:携带传输通道2的标识信息的End Marker数据包1或指示创建该End Marker数据包1的信息。
需要说明的是,End Marker数据包1在传输通道0传输,却携带传输通道2的标识信息的原因是:
一方面,传输通道2与转发隧道间具有对应关系。具体来说,由于源接入网设备与目标接入网设备之间可能存在多个转发隧道,该转发隧道可用于发送不同终端设备的数据,比如除了UE2之外的其他终端设备的数据,也可用于发送UE2在其他传输通道中传输的数据。各转发隧道可以与各UE的传输通道对应。为了便于源接入网设备在接收到该EndMarker数据包1时,确定通过哪个转发隧道向目标接入网设备发送该End Marker数据包1,该End Marker数据包1中可以携带传输通道2的标识信息,以便于源接入网设备根据该传输通道2的标识信息确定与之对应的转发隧道。从而可以避免在错误的转发隧道发送该EndMarker数据包1,对其他终端设备的转发隧道或UE2的其他转发隧道中的数据传输造成影响。另一方面,可以避免对该多播群组中的其他终端设备(如UE1)的数据传输造成影响。由于该传输通道0中传输的多播数据是发送给与之对应的多播群组的。源接入网设备并不因接收到End Marker数据包1而中断向源小区中属于该多播群组中的其他传输通道发送多播数据。若在该End Marker数据包1中携带传输通道2的标识信息,接收到该End Marker数据包1的源接入网设备便可以确定,不需要再继续通过与该传输通道2对应的转发隧道向目标接入网设备转发多播数据,而不会影响其他终端设备接收该多播数据。目标接入网设备也可以基于对End Marker数据包1的接收,确定不再从转发隧道接收多播数据。
在本申请实施例中,End Marker数据包1可以由SMF生成并发送至UPF,也可以由SMF指示UPF生成。本申请对此不作限定。若SMF指示UPF生成End Marker数据包1,则SMF可以向UPF发送指示创建End Marker数据包1的信息。例如,SMF可以将传输通道2的标识信息发送给UPF,以便于UPF创建携带该传输通道2的标识信息的End Marker数据包1。
可选地,SMF还可以进一步指示UPF在哪个传输通道上发送该End Marker数据包1。在本实施例中,SMF可以指示UPF在传输通道0中发送该End Marker数据包1。由于经传输通道0到达源接入网设备的多播数据的数据包和End Marker数据包的先后顺序与UPF发送的先后顺序一致,故不会出现乱序或丢包的情况。可选地,源接入网设备便可以确定在接收到End Marker数据包1之后,不再通过转发隧道向目标接入网设备转发多播数据。
在步骤612中,UPF向源接入网设备发送第二End Marker数据包。相应地,在步骤612中,源接入网设备接收来自UPF的第二End Marker数据包。
在步骤613中,源接入网设备向目标接入网设备发送第一End Marker数据包。相应地,在步骤613中,目标接入网设备接收来自源接入网设备的第一End Marker数据包。
如前所述,UPF可以在传输通道0中发送针对多播数据的End Marker数据包1,还可以在传输通道2中发送针对其他数据的End Marker数据包2。应理解,End Marker数据包1和End Marker数据包2并不一定是同时发送的,本申请对于End Marker数据包1和End Marker数据包2的发送顺序并不做限定。
源接入网设备可以通过转发隧道向目标接入网设备发送第一End Marker数据包。与方法400所示的实施例相似,源接入网设备向目标接入网设备发送的第一End Marker数据包可能是从UPF接收到的针对多播数据的第二End Marker数据包;也可能是基于从UPF接收到的针对多播数据的第二End Marker数据包(也即上述End Marker数据包1)和针对单播数据的End Marker数据包(也即上述End Marker数据包2),而发送的针对单播数据的EndMarker数据包2。也即,该第一End Marker数据包与第二End Marker数据包可以是相同的End Marker数据包,也可以是不同的End Marker数据包。本申请对此不做限定。
一种可能的方式是,UPF在传输通道0(比如PDU会话0)中发送针对多播数据的EndMarker数据包1,还可以在传输通道2(比如PDU会话2)中发送针对其他数据的End Marker数据包2。源接入网设备可以将接收到的End Marker数据包1和End Marker数据包2直接转发给目标接入网设备。目标接入网设备在接收到End Marker数据包1和End Marker数据包2之后,便可以确定不再从转发隧道接收数据。
另一种可能的方式是,UPF可以在传输通道0(比如PDU会话0中的一个多播专用QoSFlow)中发送针对多播数据的End Marker数据包1,还可以在传输通道2(比如PDU会话2中的一个单播QoS Flow)中发送针对其他数据(如单播QoS Flow中传输的单播数据)的EndMarker数据包2。源接入网设备可以在接收到End Marker数据包1和End Marker数据包2后,可以向目标基站发送单播QoS Flow中的End Marker数据包2,而不发送多播专用QoS Flow中的End Marker数据包1。目标接入网设备在接收到End Marker数据包2之后,便可以确定不再从转发隧道接收数据。此情况下,源接入网设备在转发End Marker数据包2之前,需要确保通过多播专用QoS Flow和单播QoS Flow传输的数据包都不再需要通过源接入网设备转发,比如在接收到来自UPF的End Marker数据包1和End Marker数据包2之后发送。
在后一种实现方式中,源接入网设备向目标接入网设备不发送针对多播数据的End Marker数据包,即End Marker数据包1,而只发送针对单播数据的End Marker数据包,即End Marker数据包2。因此目标接入网设备可以参照已有技术中的方法来处理该EndMarker数据包。
可选地,目标接入网设备在接收到第一End Marker数据包之后,可以就此释放与源接入网设备之间的转发隧道,或者,也可以在后续步骤619发送资源释放请求消息之后,释放与源接入网设备之间的转发隧道。本申请对此不作限定。
需要说明的是,由于UPF向源接入网设备发送第二End Marker数据包的传输通道和发送第二数据包的传输通道为同一个传输通道,通常情况下,源接入网设备对数据包的接收顺序与UPF的发送顺序是一致的。因此目标接入网设备可以在接收到第一End Marker数据包之后,停止从源接入网设备接收第二数据包。
在步骤614中,UPF向目标接入网设备发送数据#1的数据包。相应地,在步骤614中,目标接入网设备接收来自UPF的数据包。
UPF在向目标接入网设备发送了End Marker数据包1之后,便可以确定目标接入网设备不再需要从转发隧道接收多播数据的数据包。UPF随后可以通过与目标接入网设备间的下行用户连接发送数据#1的数据包。与方法400相似,该数据#1的数据包可以记为第一数据包。由于UE2的切换,传输通道2的传输路径发生了变化。UPF可以通过该传输通道2向目标接入网设备发送第一数据包。与此同时,原本通过传输通道2传输的其他数据也可以继续被发送给目标接入网设备。
在步骤615中,目标接入网设备向UE2发送第一数据包。
目标接入网设备在接收到End Marker数据包1之后,便可以向UE2发送从传输通道2中接收到的第一数据包。
在步骤616中,UPF向SMF发送N4消息,该N4消息可理解为是对步骤611中的第四消息的响应,可用于指示UE2的多播数据的传输的配置完成。相应地,在步骤616中,SMF接收来自UPF的N4消息。
在步骤617中,SMF向AMF发送N11消息,该N11消息可理解为是对步骤410中的第三消息的响应,可用于指示路径切换完成。相应地,在步骤617中,AMF接收来自SMF的N11消息。
与步骤610对应,该N11消息可以是Nsmf接口PDU会话更新会话管理上下文响应(Nsmf_PDUSession_UpdateSMContext Response)消息。
AMF可以在步骤618中向目标接入网设备发送N2消息,该N2消息可以理解为是对步骤609中的N2消息的响应,可用于指示路径切换完成。相应地,目标接入网设备可以在步骤618中接收来自AMF的N2消息。
应理解,与上文方法400中的步骤418相同,步骤618可以是Xn切换场景下执行的步骤。在N2切换场景下,该步骤618并不一定执行。
与步骤609对应,该N2消息可以是路径切换响应(path switch response)消息。
在步骤619中,目标接入网设备向源接入网设备发送资源释放请求消息,以请求释放UE2的上下文。相应地,在步骤619中,源接入网设备接收来自目标接入网设备的资源释放请求消息。
在本实施例中,UE2的上下文例如可以转发隧道的资源。因此释放UE2的上下文可以包括释放转发隧道的资源。
应理解,步骤619可以是Xn切换场景下执行的步骤。在N2切换场景下,该步骤619并不一定执行。
由此,目标接入网设备与源接入网设备间的转发隧道得以释放。
基于上文所述的方法,UE2在接收多播数据的同时完成了切换。源接入网设备在向目标接入网设备请求切换的同时,将用于传输多播数据的信息发送给目标接入网设备,以便于目标接入网设备基于该信息向UE2转发该多播数据,并在路径切换后向UE2发送内容相同的数据#1,从而可以避免对多播数据的数据包的丢失,有利于获得完整的数据。保证了UE2在多播数据的接收过程中无延迟的切换,同时保证了数据传输性能。
为了更好地理解本实施例,下面结合图7所示的例子来说明上述方法600。图7所示的示例中,传输通道为PDU会话,其中,传输通道0的具体形式可以是UE1的PDU会话1,传输通道2的具体形式可以是UE2的PDU会话2。
如图7所示,在图7的a)中,UE1和UE2均为驻留在源小区中的终端设备。此时,PDU会话1和PDU会话2均为建立在源接入网设备与UPF之间的传输通道。UPF可以通过UE1的PDU会话1向源接入网设备发送多播数据。源接入网设备可以将接收到的多播数据发送给源小区中与该多播数据对应的多播群组中的终端设备,比如包括上述UE1和UE2。
在图7的b)中,UE2由源接入网设备切换至目标接入网设备,或者说,由源小区切换到目标小区。源接入网设备可以将PDU会话1中接收到的多播数据的数据包(例如上述第二数据包)通过源接入网设备与目标接入网设备之间的转发隧道转发给目标接入网设备。目标接入网设备继而可以将从转发隧道接收到的第二数据包发送给UE2。
在图7的c)中,UPF可以在PDU会话1中发送针对多播数据的End Marker数据包1,还可以在PDU会话2中发送针对其他数据的End Marker数据包2。源接入网设备可以通过转发隧道向目标接入网设备转发上述End Marker数据包1和End Marker数据包2。
应理解,图中所示仅为示意。End Marker数据包1和End Marker数据包2并不一定是同时发送的,本申请对于End Marker数据包1和End Marker数据包2的发送顺序并不做限定。
在图7的d)中,不同于a)、b)、c)中所示,PDU会话2的传输路径发生了改变,不再是建立在UPF和源接入网设备之间的传输通道,而是建立在UPF和目标接入网设备之间的传输通道。UPF可以通过PDU会话2向目标接入网设备发送数据#1的数据包(例如上述第一数据包)和其他数据的数据包。目标接入网设备将接收到的数据#1的数据包和其他数据的数据包发送给UE2。
由此,UE2在切换到目标接入网设备的同时,仍然可以保证对多播数据的完整接收。
图8是本申请又一实施例提供的切换方法800的示意性流程图。如图8所示,该方法800可以包括步骤801至步骤811。下面对方法800中的各步骤做详细说明。
在步骤801中,UPF向源接入网设备和目标接入网设备发送多播数据。相应地,在步骤801中,源接入网设备和目标接入网设备分别接收来自UPF的多播数据。
假设源小区中的UE1和UE2请求的数据内容相同,应用服务器可以基于源小区中的UE对数据的请求,将请求的数据发送至UPF。UPF可以通过IP多播(IP multicast)的方式或者通过多播传输通道,向源接入网设备发送数据。该数据即多播数据。
与此同时,目标小区中的终端设备也可以请求多播数据。UPF也可以通过IPmulticast的方式或多播传输通道向目标接入网设备发送多播数据。在本实施例中,为便于区分和说明,将目标接入网设备从UPF接收到而未经由源接入网设备转发的该多播数据的数据包记作第一数据包。
一示例,UPF通过IP multicast的方式发送多播数据。
应理解,IP multicast技术中,源主机可以向多个目标主机发送数据。这多个目标主机可以称为组播组。当组播组中的目标主机请求数据时,源主机只需要发送一份数据,并将数据的目的地址设置为组播组的地址。这样,凡是属于该组播组的成员,都可以接收到一份源主机发送的数据的拷贝。
在本实施例中,一种方案是,若UPF希望通过IP multicast的方式向源接入网设备发送多播数据,可以将该多播数据的目的地址设置为源接入网设备的地址。若UPF希望通过IP multicast的方式向其他设备发送多播数据,也可以将该多播数据的目的地址设置为其他设备的地址。或者另一种方案是,若UPF希望通过IP multicast的方式向源接入网设备发送多播数据,可以将该多播数据的目的地址设置为多播数据对应的IP多播地址。若UPF希望通过IP multicast的方式向其他设备发送多播数据,也可以将该多播数据的目的地址也设置为多播数据对应的IP多播地址。
该多播数据的目的地址可以为多个。多播数据可以经由不同的路径到达不同的设备。例如,多播数据自UPF发出后经由一个或多个路由器的转发到达源接入网设备的路径可以记为路径1。多播数据自UPF发出后经由一个或多个路由器的转发到达目标接入网设备的路径可以记为路径2。本申请对于UPF发送多播数据的目的地址不作限定。UPF在向源接入网设备发送多播数据的同时,还可以向其他设备发送该多播数据。
由于UPF只需发送一份数据,该数据便可到达多个设备。因此UPF发送的数据包可以认为是天然同步的。只是发送至不同的接入网设备的路径中,经历了不同的路由器的转发,到达的时间可能会不一致。但可以理解,只要UPF发送了某一数据包,在传输路径无异常的情况下,数据包都会到达接入网设备。
另一示例,UPF通过多播传输通道发送多播数据。该多播数据可以经由UPF和源接入网设备之间的多播传输通道到达源接入网设备。
如前所述,该多播传输通道例如可以包括但不限于,多播专用PDU会话、多播专用隧道、多播专用QoS Flow、携带传输多播数据指示信息的单播QoS Flow,或其他可专门用于传输多播数据的通道。
一种可能性是,UPF在通过不同的多播传输通道向不同的接入网设备发送数据时,各多播传输通道中的数据包的序列号是同步的(例如,针对不同的接入网设备,在某一时刻,发送出的数据包的序列号是相同的)。
另一种可能性是,UPF在通过不同的多播传输通道向不同的接入网设备发送数据也可以是不同步的(例如,针对不同的接入网设备,在某一时刻,发送出的数据的序列号是不同的),但是UPF会维护UPF到每一个接入网设备的数据包的序列号,也就是维护每个多播传输通道中的数据包的序列号。这样,UPF可以针对路径状态的不同,动态调整数据传输的速率。
可以理解,如果不同的多播传输通道承载的多播数据的序列号相同,那么在不同的多播传输通道中承载的数据包的净荷部分的内容可以是相同的。
在步骤802中,源接入网设备向该多播群组中的各UE发送该多播数据。相应地,在步骤802中,该多播群组中的各UE接收多播数据。
在步骤803中,源接入网设备根据UE2上报的测量报告确定UE2需要切换。
在步骤804中,源接入网设备向目标接入网设备发送第一消息,该第一消息用于请求将为UE2切换至目标接入网设备建立资源。相应地,在步骤804中,目标接入网设备接收来自源接入网设备的第一消息。
可选地,该第一消息中携带用于传输多播数据的信息。
在步骤805中,目标接入网设备向源接入网设备发送第二消息,该第二消息用于指示目标接入网设备上建立的资源。相应地,在步骤805中,源接入网设备接收来自目标接入网设备的第二消息。
在本实施例中,目标接入网设备上建立的资源可以包括为UE2切换到目标接入网设备而建立的资源。
可选地,该第二消息中携带接入网隧道信息,该接入网隧道信息可用于指示用于转发多播数据的转发隧道的标识。在本实施例中,该转发隧道可用于源接入网设备向目标接入网设备转发多播数据。示例性地,该转发隧道可以是针对多播传输通道创建的转发隧道,或者,该转发隧道可以用于传输该多播传输通道上的数据。
在步骤806中,UE2从源接入网设备切换至目标接入网设备。
在步骤807中,源接入网设备通过转发隧道向目标接入网设备转发在路径1中接收到的数据包。相应地,在步骤807中,目标接入网设备通过转发隧道接收来自源接入网设备的数据包。
为便于区分和说明,将目标接入网设备通过转发隧道接收到的来自源接入网设备的数据包例如记为第二数据包。该第二数据包也是上述多播数据的数据包。
目标接入网设备在某一段时间可能可以从源接入网设备和UPF分别接收到多播数据的数据包。其中,从源接入网设备接收到的多播数据的数据包是通过路径1传输的第二数据包,从UPF接收到的多播数据的数据包是通过路径2传输的第一数据包。
这里,路径1可以包括UPF和源接入网设备之间的一个或多个路由器,也可以是指UPF和源接入网设备之间的多播传输通道。与之相似,路径2可以包括UPF和目标接入网设备之间的一个或多个路由器,也可以是指UPF和目标接入网设备之间的多播传输通道。本申请对此不作限定。
在步骤809中,目标接入网设备向UE2发送数据包。
如前所述,路径1和路径2中所经历的路径不同。例如,路由器可能不同,数量也可能不同;又例如,传输通道不同。这可能会导致路径1和路径2中对数据包的传输速率不同。在本实施例中,目标接入网设备可以将路径2上接收到的数据包暂时缓存在本地。根据从两个路径接收到的数据包的序列号的大小关系来判断向UE2转发哪个数据包。
例如,从源接入网设备接收到的第二数据包的序列号(例如第一序列号)小于从路径2接收到的第一数据包的序列号(例如记为第三序列号)时,便可以判断路径2的数据包的传输速率较快。处于第一序列号与第三序列号间的序列号所对应的数据包未被接收到。若此时释放该转发隧道,目标接入网设备将会丢失部分数据包。因此在第一序列号小于第三序列号的情况下,目标接入网设备可以继续转发来自源接入网设备的第二数据包。
示例性地,在从源接入网设备接收到的第二数据包的第一序列号大于或等于从路径2接收到的第一数据包的第三序列号时,便可以判断在路径2的序列号之前的来自源接入网设备的数据包已经被成功接收。若此时释放该转发隧道,目标接入网设备不会丢失数据包。因此在第一序列号大于或等于第三序列号的情况下,目标接入网设备可以转发来自路径2的第一数据包,而不再需要通过转发隧道接收来自源接入网设备的第二数据包。
在步骤810中,源接入网设备停止向目标接入网设备转发数据包。
源接入网设备可以基于多种不同的条件,停止向目标接入网设备转发数据包。
在一种实现方式中,目标接入网设备在确定路径1的序列号大于或等于路径2的序列号的情况下,向源接入网设备发送资源释放请求消息,以请求释放UE2的上下文。源接入网设备可以基于接收到的资源释放请求消息,停止向目标接入网设备转发数据包。
这里,目标接入网设备可以直接向源接入网设备发送资源释放请求消息,可以通过核心网设备的转发向源接入网设备发送该资源释放请求消息。这取决于该目标接入网设备与源接入网设备是否支持Xn接口的通信。例如,若目标接入网设备和源接入网设备支持Xn接口的通信,则该目标接入网设备可以直接向源接入网设备发送资源释放请求消息,该资源释放请求消息为Xn接口消息。若目标接入网设备和源接入网设备不支持Xn接口的通信,则该目标接入网设备可以经由核心网网元,如AMF,向源接入网设备发送资源释放请求消息,该资源释放请求消息为N2消息。
在另一种实现方式中,核心网设备可以自行确定是否释放UE2的上下文资源。比如,AMF可以自行向源接入网设备发送资源释放请求消息。源接入网设备可以基于该资源释放请求消息,停止向目标接入网设备转发数据包,释放UE2的上下文。
在又一种实现方式中,源接入网设备可以基于本地计时器所计时长来确定是否释放UE2的上下文。例如,源接入网设备可以在本地计时器超时(或者说,过期)后,自动释放UE2的上下文。源接入网设备也就此停止向目标接入网设备转发数据包。
在再一种实现方式中,核心网设备可以基于计时器所计时长来确定是否释放UE2的上下文。例如,AMF可以在本地计时器所计的时长达到预设门限后,向源接入网设备发送资源释放请求消息,以指示源接入网设备释放UE2的上下文。源接入网设备可以基于该资源释放请求消息,停止向目标接入网设备转发数据包,释放UE2的上下文。
可选地,上述资源释放请求消息中携带切换完成信息。源接入网设备可以基于该切换完成信息,确定可以释放UE2的上下文。源接入网设备可以基于切换完成信息,停止向目标接入网设备转发数据包,释放UE2的上下文。
可选地,该方法800还包括步骤811,源接入网设备释放UE2的上下文。
如前所述,上述释放UE2的上下文可以包括释放源接入网设备与目标接入网设备之间的转发隧道的资源。
基于上文所述的方法,UE2在接收多播数据的同时实现了小区切换。源接入网设备在向目标接入网设备请求切换的同时,将用于传输多播数据的信息发送给目标接入网设备,以便于目标接入网设备基于该信息向UE2转发多播数据,并在路径切换后向UE2发送内容相同的数据#1,从而可以避免对多播数据的数据包的丢失,有利于获得完整的数据。保证了UE2在多播数据的接收过程中无延迟的切换,同时保证了数据传输性能。
为了更好地理解本实施例,下面结合图9所示的例子来说明上述方法800。图9所示的示例中,UPF通过IP multicast的方式发送多播数据。
如图9所示,在图9的a)中,UE1和UE2均为驻留在源小区中的终端设备。此时,多播数据可以经由UPF和源接入网设备之间的一个或多个路由器的转发到达源接入网设备。即,UPF可以通过路径1向源接入网设备发送多播数据。源接入网设备可以将接收到的多播数据发送给源小区中与该多播数据对应的多播群组中的终端设备,比如包括上述UE1和UE2。
在图9的b)所示,UE2由源接入网设备切换至目标接入网设备,或者说,由源小区切换到目标小区。源接入网设备可以将路径1中接收到的第二数据包通过源接入网设备与目标接入网设备之间的转发隧道转发给了目标接入网设备。与此同时,该多播数据可以经由UPF和目标接入网设备之间的一个或多个路由器的转发到达目标接入网设备。即,UPF可以通过路径2向目标接入网设备发送该多播数据。目标接入网设备可以通过路径2接收第一数据包。
如果目标接入网设备从路径2接收到的第二数据包的序列号大于从转发隧道接收到的由路径1传输的第一数据包的序列号,目标接入网设备可以从转发隧道接收到的数据包发送给UE2,并可暂时将从路径2接收到的数据包缓存在本地。
如果目标接入网设备从路径2接收到的第二数据包的序列号小于或等于从转发隧道接收到的第一数据包的序列号,便可以停止从转发隧道接收第二数据包。
在图9的c)中,目标接入网设备可以将缓存在本地的第一数据包发送给UE2,并可继续通过路径2接收后续的数据包,将接收到的数据包转发给UE2。
由此,UE2在切换到目标接入网设备的同时,仍然可以保证对多播数据的完整接收。基于上文所述的方法,UE2在接收多播数据的同时完成了切换。源接入网设备在向目标接入网设备请求切换的同时,将用于传输多播数据的信息发送给目标接入网设备,以便于目标接入网设备基于该信息向UE2转发该多播数据,并在路径切换后向UE2发送内容相同的数据#1,从而可以避免对多播数据的数据包的丢失,有利于获得完整的数据。保证了UE2在多播数据的接收过程中无延迟的切换,同时保证了数据传输性能。
图10是本申请一实施例提供的切换方法1000的示意性流程图。如图10所示,该方法1000可以包括步骤1001至1012。下面对方法400中的各步骤做详细说明。
在步骤1001中,源小区中属于同一多播群组的各终端设备接收多播数据。
应理解,步骤601的具体过程与上文方法400中的步骤401的具体过程相同,为了简洁,这里不再重复。
在本申请实施例中,各终端设备可以通过已有的传输通道(如,PDU会话)来接收上述多播数据,也可以基于上述多播数据的传输创建传输通道,进而基于新创建的传输通道接收上述多播数据。
可选地,在方法1001之前,该方法还包括,步骤1002,源小区中的各UE创建各自的传输通道。
该源小区中的终端设备例如可以包括但不限于UE1和UE2。各终端设备可以各自创建传输通道,以便传输数据。例如,UE1可以创建传输通道1,UE2可以创建传输通道2。各UE创建传输通道的具体过程可以参考现有技术,为了简洁,这里不做详述。
在本实施例中,传输通道1可以是单播传输通道,也可以是多播传输通道。与之相似,传输通道2可以是单播传输通道,也可以是多播传输通道。本申请对此不做限定。
假设该源小区中的UE1和UE2请求的数据内容相同,因此UPF可以对传输通道1和传输通道2中内容相同的数据进行合并,通过多播的方式来向源小区中的UE1和UE2发送该数据。该UE1和UE2构成一个多播群组。UPF通过多播的方式为该多播群组发送数据。该多播群组对应的数据可以称为多播数据。
在本实施例中,对于源小区中接收多播数据的终端设备来说,该多播数据可以通过UE1或UE2中任一个的传输通道来传输,或者,该多播数据可以通过网络建立的专门用于传输此多播数据的多播共享传输通道发送来传输。本申请对此不作限定。
为便于说明,本实施例中假设传输多播数据的传输通道为传输通道0。该传输通道0例如可以是UE1的传输通道1,也可以是上述单独建立的多播共享传输通道。
关于步骤1002的具体内容可以参考上文方法600中对步骤602的详细说明,为了简洁,这里不再重复。
在步骤1003中,源接入网设备根据UE2上报的测量报告确定UE2需要切换。
在步骤1004中,源接入网设备向AMF发送N2消息,该N2消息用于通知AMF,UE2将切换到目标接入网设备。相应地,在步骤1004中,AMF接收来自源接入网设备的N2消息。
可选地,该N2消息中包含在目标接入网设备建立的传输通道(例如PDU会话等)的列表以及对应的会话中成功建立的QoS flow的列表信息。
此外,该N2消息中还可以携带切换指示。
在一种实现方式中,该切换指示用于指示UE2将由源接入网设备切换至目标接入网设备。
在另一种实现方式中,该切换指示不仅用于指示UE2将由源接入网设备切换至目标接入网设备,还用于指示UE2将由接收多播数据切换为接收单播数据。
在本实施例中,UE2在源小区中接收到的多播数据为多播数据,在切换为接收单播数据后接收到的数据为数据#1。应理解,该数据#1是与多播数据内容相同的数据。事实上,该数据#1也就是UE2请求的数据,但由于该源小区中存在内容相同的多播数据的传输而被过滤了。而在确定UE2将切换至目标接入网设备之后,源接入网设备可以确定不再向UE2发送多播数据,而发送数据#1。
在一种可能的设计中,该N2消息为N2接口PDU会话请求(N2 PDU SessionRequest)消息。
在步骤1005中,AMF向SMF发送第三消息,该第三消息用于指示上述用于传输多播数据的信息,且该第三消息中携带切换指示。相应地,在步骤1005中,SMF接收来自AMF的第三消息。
AMF可以通过第三消息请求SMF配置UE2的传输通道上的数据的传输。该传输通道可用于传输UE2请求的数据,即数据#1。而数据#1对应于上述用于传输多播数据的信息,也即与上述多播数据是内容相同的数据,故也可以认为该第三消息是用于请求SMF配置多播数据的传输。
该第三消息可以是N11消息。
SMF根据第三消息确定上述用于传输多播数据的信息的具体方式可以参考上文方法400中的相关描述,为了简洁,这里不再赘述。
如前所述,在一种实现方式中,该切换指示可用于指示UE2将由源小区切换至目标接入网设备。此情况下,SMF可以根据该切换指示,确定不再过滤UE2的数据#1。也就是说,SMF也可以确定UE2由接收多播数据切换为接收单播数据。
在另一种实现方式中,该切换指示不仅用于指示UE2将由源接入网设备切换至目标接入网设备,还用于指示UE2将由接收多播数据切换为接收单播数据。
进一步地,SMF还可以根据用于传输多播数据的信息,进一步确定该数据#1被映射到哪个传输通道上。由于SMF预先保存了多播数据与传输通道的映射关系,在接收到该N11消息后,可以根据用于传输多播数据的信息确定数据#1的传输通道,也即可以确定将数据#1映射到哪个传输通道上。如前所述,数据#1原本是要通过PDU会话2传输的,但由于被过滤而未被传输。但SMF可以基于此,预先保存多播数据与PDU会话2的对应关系。因此,SMF在确定不再过滤数据#1之后,便可以确定将该数据#1映射到PDU会话2上传输。
SMF也可以不确定或者不向UPF指示将数据#1映射到哪个传输通道上,而将上述多播数据与传输通道的映射关系发送给UPF,由UPF去确定将数据#1映射到哪个传输通道上。
在一种可能的设计中,该第三消息为Nsmf接口PDU会话更新会话管理上下文请求(Nsmf_PDUSession_UpdateSMContext Request)消息。
在步骤1006中,SMF向UPF发送第四消息,该第四消息用于请求修改N4会话。相应地,在步骤1006中,UPF接收来自SMF的第四消息。
具体来说,该第四消息用于请求将UE2由接收多播数据切换为接收数据#1。这可以由UPF的配置来实现。在一种实现方式中,UPF可以对数据#1不作过滤,而将其映射到SMF所指示的传输通道上传输。
该第四消息可以是N4消息。
在一种可能的设计中,该第四消息为N4会话修改请求(N4 Session ModificationRequest)消息。
在步骤1007中,UPF向SMF发送N4消息,该N4消息用于指示已经完成N4会话的修改。相应地,在步骤1007中,SMF接收来自UPF的N4消息。
该N4消息可以理解为是对步骤1006中的第三消息的响应,可用于通知SMF已经完成N4会话的修改。更具体地说,该N4消息可用于通知SMF已经将UE2由接收多播数据切换为接收单播数据。
在一种可能的设计中,该N4消息是N4会话修改响应(N4 Session ModificationResponse)消息。
在步骤1008中,SMF向AMF发送N11消息。相应地,在步骤1008中,AMF接收来自SMF的N11消息。
在步骤1009中,AMF向源接入网设备发送N2消息。相应地,在步骤1009中,源接入网设备接收来自AMF的N2消息。
该N11消息可以理解为是对步骤1005中的第三消息的响应,可用于通知SMF已经将UE2由接收多播数据切换为接收单播数据。AMF可基于对该N11消息的接收,进一步向源接入网设备发送N2消息,以通知源接入网设备核心网已经将UE2由接收多播数据切换为接收单播数据。基于此,源接入网设备便可以确定不再向UE2发送多播数据,而发送单播数据。
在一种可能的设计中,该N11消息为Nsmf接口PDU会话更新会话管理上下文响应(Nsmf_PDUSession_UpdateSMContext Response)消息。
在一种可能的设计中,该N2消息为PDU会话响应(PDU Session Response)消息。
在步骤1010中,源接入网设备向UE2发送RRC重配置消息,该RRC重配置消息用于指示UE2不再接收多播数据。相应地,在步骤1010中,UE2接收来自源接入网设备的RRC重配置消息。
另一方面,UPF基于在步骤1006中接收到的来自SMF的第四消息,便不再对数据#1进行过滤。
在步骤1011中,UPF通过PDU会话2向源接入网设备发送数据#1。相应地,在步骤1011中,源接入网设备通过PDU会话2接收来自UPF的数据#1。
如前所述,UPF可以根据SMF的指示,将数据#1映射到PDU会话2上传输。或者,UPF也可以基于SMF发送的多播数据与传输通道的映射关系,确定将数据#1映射到哪个传输通道上。具体确定过程与SMF确定的过程相同,为了简洁,这里不再重复。
UPF通过PDU会话2向源接入网设备发送数据#1后,源接入网设备可以在PDU会话2中接收到该数据#1,但可能还未接收到UPF向UE2发送单播数据的通知,因此仍然不知道向UE2发送的数据已由多播数据(即多播数据)切换为单播数据(即数据#1),故源接入网设备仍然向UE2发送多播数据。
在步骤1012中,源接入网设备向UE2发送数据#1。相应地,在步骤1012中,UE2接收来自源接入网设备的数据#1。
源接入网设备可以基于在步骤1010中接收到的N2消息,确定不再向UE2发送多播数据,而发送单播数据。因此源接入网设备可以向UE2发送RRC重配置消息。该RRC重配置消息可用于指示UE2不再使用G-RNTI接收多播数据,而使用预先为UE2配置的C-RNTI接收多播数据。
图10中虽未予以示出,但可以理解,UPF仍然可以继续向源接入网设备发送多播数据,源接入网设备也可以继续向源小区中属于多播数据对应的多播群组的UE(例如包括UE1)发送多播数据。也就是说,除了即将切换的UE2之外,源小区中属于该多播群组中的其他UE仍然可以接收到多播数据。
由此,UE2从接收多播数据切换成了接收单播数据。此后,UE2可以按照现有技术中的方法执行从源接入网设备到目标接入网设备的切换。
需要说明的是,上述步骤1004至步骤1012的流程可以在步骤1003之后执行,为便于理解和说明,下面进一步结合现有技术中的切换流程来说明执行上述步骤1004至步骤1012的时机。应理解,由于下文所示的切换流程为现有技术,本文中仅为便于说明与上述步骤1004至步骤1012的执行的先后顺序而示出,故下文所述的流程中仅示出了与步骤1004至步骤1012相关的部分流程,而未对完整的切换流程予以示出。图中所示的步骤仅为切换流程中的部分步骤,不应对本申请构成任何限定。关于切换的具体流程可以参看3GPP协议TS23.502、TS38.300等中的相关描述,本文不作赘述。
图11示出了的Xn切换的部分流程。
在步骤1100中,AMF向各接入网设备(例如包括源接入网设备和目标接入网设备)提供移动性控制信息。
在步骤1101中,源小区中的UE(例如可以是上文所述的UE2)进行测量控制和上报。UE2可以将测量报告上报给源接入网设备。
在步骤1102中,源接入网设备根据测量报告,确定UE2需要切换至目标接入网设备。
应理解,步骤1101和步骤1102可对应于上文方法1000中的步骤1003。
在步骤1103中,源接入网设备向目标接入网设备发送切换请求(handoverrequest)消息。
在步骤1104中,目标接入网设备确定允许UE2切换至本小区,并在步骤1105中向源接入网设备发送切换请求确认(handover request acknowledge)消息。该切换请求确认消息中携带发给UE2的容器信息。该容器信息中例如包括目标小区标识、目标接入网设备分配给UE2的C-RNTI和安全识别信息等。
在步骤1106中,源接入网设备向UE2发起切换,并将上述容器信息发送给UE2。
此后,UE2便可以执行从源接入网设备至目标接入网设备的切换流程。
上述步骤1004至步骤1012例如可以在步骤1102和步骤1103之间执行,也可以在步骤1105和步骤1106之间执行。本申请对此不作限定。
由于后续流程不涉及上述步骤1004至步骤1012的执行先后顺序,且该切换流程为现有技术,为了简洁,这里不作详述。
图12和图13示出了N2切换的部分流程。其中,图12所示的流程N2切换的准备阶段的部分流程;图13所示的流程是N2切换的执行阶段的部分流程。
下面先说明图12所示的N2切换的准备阶段与上述步骤1004至步骤1012的执行先后顺序。
在步骤1201中,源接入网设备确定UE2需要进行N2切换。
源接入网设备例如可以根据UE2上报的测量报告确定将UE2切换到目标接入网设备。由于目标接入网设备与源接入网设备之间不支持Xn接口的通信,所以该切换为N2切换。由此,源接入网设备可以触发UE2的N2切换。
在步骤1202中,源接入网设备向源AMF发送切换需求(Handover Required)消息。
该切换需求消息中可以包含目标接入网设备的标识信息、需要切换的PDU会话的标识信息以及待发送给目标接入网设备的容器信息等。
在步骤1203,源AMF根据目标接入网设备的标识信息确定目标AMF。
源AMF可以根据目标接入网设备的标识信息,判断是否能够继续为该UE2提供服务。若无法继续服务,则源AMF可以选择新的AMF(即,目标AMF)为UE2提供服务。
如果UE2在N2切换的准备阶段由接收多播数据转为接收单播数据,上述步骤1004至步骤1012例如可以在步骤1202之前执行。
由于后续流程不涉及上述步骤1004至步骤1012的执行先后顺序,且该切换流程为现有技术,为了简洁,这里不作详述。
下面说明图13所示的N2切换的执行阶段与上述步骤1004至步骤1012的执行先后顺序。
在步骤1301中,源AMF向源接入网设备发送切换命令(Handover Command)。
该切换命令中携带切换的信息,如需要切换的UE的PDU会话的标识信息、目标接入网设备的标识信息、目标小区的标识等本申请对此不作限定。
在步骤1302中,源接入网设备将切换命令转发给需要切换的UE(如UE2)。
在步骤1303中,源接入网设备将要发送给UE2的数据转发至目标接入网设备,以便通过目标接入网设备向UE2转发。
在步骤1304中,UE2与目标小区同步。
在步骤1305中,UE2向源接入网设备发送切换确认(Handover Confirm)消息。
在步骤1306中,目标接入网设备向UE2发送从源接入网设备接收到的数据。
如果UE2在N2切换的执行过程由接收多播数据转为接收单播数据,上述步骤1004至步骤1012例如可以在步骤1302之前执行。
由于后续流程不涉及步骤1004至步骤1012的执行先后顺序,且该切换流程为现有技术,为了简洁,这里不作详述。
上文结合多个切换流程详细描述了将图10提供的方法1000应用到现有的切换流程中的具体示例。但这些示例仅为便于理解而示出,不应对本申请构成任何限定。
基于上文所述的方法,UE2在需要切换的情况下,可以先由接收多播数据切换为接收单播数据,然后可以基于现有的切换流程实现小区切换。从而可以避免对多播数据的数据包的丢失,有利于获得完整的数据。保证了UE2在多播数据的场景下实现无延迟的切换,同时保证了数据传输性能。
上文示出的多个实施例中,UE2切换到目标接入网设备后接收的数据为单播数据。但这并不标识UE2在目标小区中将一直接收单播数据。如果该目标小区中也存在多播数据的传输,则UE2还可以再次由接收单播数据切换为接收多播数据。UE2由接收单播数据切换接收多播数据的具体过程与上文由接收多播数据切换为接收单播数据的具体过程相似,为了简洁,这里不做详述。
在上文各实施例中,各网元可以执行各实施例中的部分或全部步骤。这些步骤或操作仅是示例,本申请实施例还可以执行其它操作或者各种操作的变形。此外,各个步骤可以按照各实施例呈现的不同的顺序来执行,并且有可能并非要执行本申请实施例中的全部操作。且,各步骤的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
图14是本申请实施例提供的通信装置的示意性框图。如图14所示,该通信装置1400可以包括处理单元1410和收发单元1420。
在一种可能的设计中,该通信装置1400可对应于上文方法实施例中的目标接入网设备,例如,可以为目标接入网设备,或者配置于目标接入网设备中的部件(如电路、芯片或芯片***等)。
应理解,该通信装置1400可对应于根据本申请实施例的方法400、方法600、方法800和方法1000中的目标接入网设备,该通信装置1400可以包括用于执行图4中的方法400、图6中的方法600、图8中的方法800以及图10中的方法1000中目标接入网设备执行的方法的单元。并且,该通信装置1400中的各单元和上述其他操作和/或功能分别为了实现图4中的方法400、图6中的方法600、图8中的方法800以及图10中的方法1000的相应流程。
在另一种可能的设计中,该通信装置1400可对应于上文方法实施例中的源接入网设备,例如,可以为源接入网设备,或者配置于源接入网设备中的部件(比如电路、芯片或芯片***等)。
应理解,该通信装置1400可对应于根据本申请实施例的方法400、方法600、方法800和方法1000中的源接入网设备,该通信装置1400可以包括用于执行图4中的方法400、图6中的方法600、图8中的方法800以及图10中的方法1000中源接入网设备执行的方法的单元。并且,该通信装置1400中的各单元和上述其他操作和/或功能分别为了实现图4中的方法400、图6中的方法600、图8中的方法800以及图10中的方法1000的相应流程。
还应理解,该通信装置1400为上述源接入网设备或目标接入网设备时,该通信装置1400中的收发单元1420可以通过收发器实现,例如可对应于图15中示出的通信装置1500中的收发器1520或图16中示出的基站1600中的RRU 1610。该通信装置1400中的处理单元1410可通过至少一个处理器实现,例如可对应于图15中示出的通信装置1500中的处理器1510或图16中示出的基站1600中的BBU 1620。
还应理解,该通信装置1400为配置于上述源接入网设备或目标接入网设备中的芯片或芯片***时,该通信装置1400中的收发单元1420可以通过输入/输出接口实现,该通信装置1400中的处理单元1410可以通过该芯片或芯片***上集成的处理器、微处理器或集成电路等实现。
在又一种可能的设计中,该通信装置1400可对应于上文方法实施例中的SMF,例如,可以为SMF,或者配置于SMF中的部件(比如电路、芯片或芯片***等)。
应理解,该通信装置1400可对应于根据本申请实施例的方法400、方法600、方法800和方法1000中的SMF,该通信装置1400可以包括用于执行图4中的方法400、图6中的方法600、图8中的方法800以及图10中的方法1000中SMF执行的方法的单元。并且,该通信装置1400中的各单元和上述其他操作和/或功能分别为了实现图4中的方法400、图6中的方法600、图8中的方法800以及图10中的方法1000的相应流程。
还应理解,该通信装置1400为SMF时,该通信装置1400中的收发单元1420可以通过收发器实现,例如可对应于图15中示出的通信装置1500中的收发器1520。该通信装置1400中的处理单元1410可通过至少一个处理器实现,例如可对应于图15中示出的通信装置1500中的处理器1510。
还应理解,该通信装置1400为配置于上述源接入网设备或目标接入网设备中的芯片或芯片***时,该通信装置1400中的收发单元1420可以通过输入/输出接口实现,该通信装置1400中的处理单元1410可以通过该芯片或芯片***上集成的处理器、微处理器或集成电路等实现。
在再一种可能的设计中,该通信装置1400可对应于上文方法实施例中的UPF,例如,可以为UPF,或者配置于UPF中的部件(比如电路、芯片或芯片***等)。
应理解,该通信装置1400可对应于根据本申请实施例的方法400、方法600、方法800和方法1000中的UPF,该通信装置1400可以包括用于执行图4中的方法400、图6中的方法600、图8中的方法800以及图10中的方法1000中UPF执行的方法的单元。并且,该通信装置1400中的各单元和上述其他操作和/或功能分别为了实现图4中的方法400、图6中的方法600、图8中的方法800以及图10中的方法1000的相应流程。
还应理解,该通信装置1400为UPF时,该通信装置1400中的收发单元1420可以通过收发器实现,例如可对应于图15中示出的通信装置1500中的收发器1520。该通信装置1400中的处理单元1410可通过至少一个处理器实现,例如可对应于图15中示出的通信装置1500中的处理器1510。
还应理解,该通信装置1400为配置于上述源接入网设备或目标接入网设备中的芯片或芯片***时,该通信装置1400中的收发单元1420可以通过输入/输出接口实现,该通信装置1400中的处理单元1410可以通过该芯片或芯片***上集成的处理器、微处理器或集成电路等实现。
图15是本申请实施例提供的通信装置1500的另一示意性框图。如图15所示,该通信装置1500包括处理器1510、收发器1520和存储器1530。其中,处理器1510、收发器1520和存储器1530通过内部连接通路互相通信,该存储器1530用于存储指令,该处理器1510用于执行该存储器1530存储的指令,以控制该收发器1520发送信号和/或接收信号。
应理解,该通信装置1500可以对应于上述方法实施例中的终端设备,并且可以用于执行上述方法实施例中网络设备或终端设备执行的各个步骤和/或流程。可选地,该存储器1530可以包括只读存储器和随机存取存储器,并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。存储器1530可以是一个单独的器件,也可以集成在处理器1510中。该处理器1510可以用于执行存储器1530中存储的指令,并且当该处理器1510执行存储器中存储的指令时,该处理器1510用于执行上述与网络设备或终端设备对应的方法实施例的各个步骤和/或流程。
可选地,上述通信装置1500可以是前文实施例中的目标接入网设备、源接入网设备、SMF或UPF。
收发器1520可以包括发射机和接收机。收发器1520还可以进一步包括天线,天线的数量可以为一个或多个。该处理器1510和存储器1530与收发器1520可以是集成在不同芯片上的器件。如,处理器1510和存储器1530可以集成在基带芯片中,收发器1520可以集成在射频芯片中。该处理器1510和存储器1530与收发器1520也可以是集成在同一个芯片上的器件。本申请对此不作限定。
可选地,该通信装置1500可以是配置在目标接入网设备、源接入网设备、SMF或UPF中的部件,如芯片、芯片***等。
收发器1520也可以是通信接口,如输入/输出接口。该收发器1520与处理器1510和存储器1520都可以集成在同一个芯片中,如集成在基带芯片中。
图16是本申请实施例提供的接入网设备的结构示意图,例如可以为基站的结构示意图。该基站1600可应用于如图1所示的***中,执行上述方法实施例中目标接入网设备或源接入网设备的功能。如图所示,该基站1600可以包括一个或多个射频单元,如远端射频单元(remote radio unit,RRU)1610和一个或多个基带单元(BBU)(也可称为分布式单元(DU))1620。
所述RRU 1610可以称为收发单元,与图14中的收发单元1420对应。可选地,该收发单元1610还可以称为收发机、收发电路、或者收发器等等,其可以包括至少一个天线1611和射频单元1612。可选地,收发单元1610可以包括接收单元和发送单元,接收单元可以对应于接收器(或称接收机、接收电路),发送单元可以对应于发射器(或称发射机、发射电路)。所述RRU 1610部分主要用于射频信号的收发以及射频信号与基带信号的转换,例如用于向终端设备发送数据包。所述BBU 1620部分主要用于进行基带处理,对基站进行控制等。所述RRU 1610与BBU 1620可以是物理上设置在一起,也可以物理上分离设置的,即分布式基站。
所述BBU 1620为基站的控制中心,也可以称为处理单元,可以与图14中的处理单元1410对应,主要用于完成基带处理功能,如信道编码,复用,调制,扩频等等。例如所述BBU(处理单元)可以用于控制基站执行上述方法实施例中关于网络设备的操作流程,例如,生成上述指示信息等。
在一个示例中,所述BBU 1620可以由一个或多个单板构成,多个单板可以共同支持单一接入制式的无线接入网(如LTE网),也可以分别支持不同接入制式的无线接入网(如LTE网,5G网或其他网)。所述BBU 1620还包括存储器1621和处理器1622。所述存储器1621用以存储必要的指令和数据。所述处理器1622用于控制基站进行必要的动作,例如用于控制基站执行上述方法实施例中关于网络设备的操作流程。所述存储器1621和处理器1622可以服务于一个或多个单板。也就是说,可以每个单板上单独设置存储器和处理器。也可以是多个单板共用相同的存储器和处理器。此外每个单板上还可以设置有必要的电路。
应理解,图16所示的基站1600能够实现图4、图6、图8或图10的方法实施例中涉及的目标接入网设备或源接入网设备的各个过程。基站1600中的各个模块的操作和/或功能,分别为了实现上述方法实施例中的相应流程。具体可参见上述方法实施例中的描述,为避免重复,此处适当省略详细描述。
上述BBU 1620可以用于执行前面方法实施例中描述的由目标接入网设备或源接入网设备内部实现的动作,而RRU 1610可以用于执行前面方法实施例中描述的目标接入网设备或源接入网设备发送或接收的动作,例如向终端设备发送或从终端设备接收的动作。具体请见前面方法实施例中的描述,此处不再赘述。
本申请实施例还提供了一种处理装置,包括处理器和接口;所述处理器用于执行上述任一方法实施例中的通信的方法。
应理解,上述处理装置可以是一个或多个芯片。例如,该处理装置可以是现场可编程门阵列(field programmable gate array,FPGA),可以是专用集成芯片(applicationspecific integrated circuit,ASIC),还可以是***芯片(system on chip,SoC),还可以是中央处理器(central processor unit,CPU),还可以是网络处理器(networkprocessor,NP),还可以是数字信号处理电路(digital signal processor,DSP),还可以是微控制器(micro controller unit,MCU),还可以是可编程控制器(programmable logicdevice,PLD)或其他集成芯片。
在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。为避免重复,这里不再详细描述。
应注意,本申请实施例中的处理器可以是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
可以理解,本申请实施例中的存储器可以是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(read-only memory,ROM)、可编程只读存储器(programmable ROM,PROM)、可擦除可编程只读存储器(erasable PROM,EPROM)、电可擦除可编程只读存储器(electrically EPROM,EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory,RAM),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的RAM可用,例如静态随机存取存储器(static RAM,SRAM)、动态随机存取存储器(dynamic RAM,DRAM)、同步动态随机存取存储器(synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(double data rateSDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM,ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM,SLDRAM)和直接内存总线随机存取存储器(directrambus RAM,DR RAM)。应注意,本文描述的***和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
根据本申请实施例提供的方法,本申请还提供一种计算机程序产品,该计算机程序产品包括:计算机程序代码,当该计算机程序代码在计算机上运行时,使得该计算机执行图4、图6、图8或图10所示实施例中任意一个实施例的方法。
根据本申请实施例提供的方法,本申请还提供一种计算机可读介质,该计算机可读介质存储有程序代码,当该程序代码在计算机上运行时,使得该计算机执行图4、图6、图8或图10所示实施例中任意一个实施例的方法。
根据本申请实施例提供的方法,本申请还提供一种***,其包括前述的目标接入网设备、源接入网设备、SMF、UPF以及终端设备中的一个或多个。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如,软盘、硬盘、磁带)、光介质(例如,高密度数字视频光盘(digital video disc,DVD))、或者半导体介质(例如,固态硬盘(solid state disc,SSD))等。
上述各个装置实施例中网络设备与终端设备和方法实施例中的网络设备或终端设备完全对应,由相应的模块或单元执行相应的步骤,例如通信单元(收发器)执行方法实施例中接收或发送的步骤,除发送、接收外的其它步骤可以由处理单元(处理器)执行。具体单元的功能可以参考相应的方法实施例。其中,处理器可以为一个或多个。
在本说明书中使用的术语“部件”、“模块”、“***”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如,部件可以是但不限于,在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示,在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中,部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外,这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地***、分布式***和/或网络间的另一部件交互的二个部件的数据,例如通过信号与其它***交互的互联网)的信号通过本地和/或远程进程来通信。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block)和步骤(step),能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的***、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的***、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
在上述实施例中,各功能单元的功能可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令(程序)。在计算机上加载和执行所述计算机程序指令(程序)时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘(solid state disk,SSD))等。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read-only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。
Claims (11)
1.一种切换方法,其特征在于,包括:
目标接入网设备接收第一消息,所述第一消息用于请求为终端设备切换至所述目标接入网设备建立资源;
所述目标接入网设备从所述第一消息中获取用于传播多播数据的信息;
所述目标接入网设备发送第二消息,所述第二消息用于指示所述目标接入网设备上已建立的所述资源;
所述目标接入网设备接收来自用户面网元的第一数据包,所述第一数据包对应于所述用于传播多播数据的信息;
所述目标接入网设备向所述终端设备发送所述第一数据包,
其中,所述第一数据包包括所述第一数据包对应的第一序列号,所述方法还包括:
所述目标接入网设备接收来自源接入网设备的第二数据包,其中,所述第二数据包对应于所述用于传播多播数据的信息,所述第二数据包包括所述第二数据包对应的第二序列号,
所述目标接入网设备向所述终端设备发送所述第一数据包,包括:
当所述第一序列号小于或等于所述第二序列号时,所述目标接入网设备向所述终端设备发送所述第一数据包;或者,
在所述目标接入网设备向所述终端设备发送所述第一数据包之前,所述方法还包括:
当所述第一序列号大于所述第二序列号时,所述目标接入网设备向所述终端设备发送所述第二数据包。
2.如权利要求1所述的方法,其特征在于,所述方法还包括:
所述目标接入网设备在本地缓存所述第一数据包,
其中,所述目标接入网设备向终端设备发送的所述第一数据包,包括:
所述目标接入网设备将本地缓存的所述第一数据包发送给终端设备。
3.如权利要求1或2所述的方法,其特征在于,所述方法还包括:
所述目标接入网设备根据所述第一序列号和所述第二序列号,确定将所述第一数据包发送给所述终端设备,
或者,
所述目标接入网设备根据所述第一序列号和所述第二序列号,确定将所述第二数据包发送给所述终端设备。
4.一种切换方法,其特征在于,包括:
源接入网设备发送第一消息,所述第一消息用于请求为终端设备切换至目标接入网设备建立资源,所述第一消息包括用于传播多播数据的信息;
所述源接入网设备接收第二消息,所述第二消息用于指示所述目标接入网设备上已建立的所述资源,
所述目标接入网设备接收来自用户面网元的第一数据包,所述第一数据包对应于所述用于传播多播数据的信息;
所述目标接入网设备向所述终端设备发送所述第一数据包,
其中,所述用于传播多播数据的信息与第一数据包相对应,所述第一数据包包括所述第一数据包对应的第一序列号,所述方法还包括:
所述源接入网设备发送第二数据包,其中,所述第二数据包对应于所述用于传播多播数据的信息,所述第二数据包包括所述第二数据包对应的第二序列号,
所述目标接入网设备向所述终端设备发送所述第一数据包,包括:
当所述第一序列号小于或等于所述第二序列号时,所述目标接入网设备向所述终端设备发送所述第一数据包;或者
在所述目标接入网设备向所述终端设备发送所述第一数据包之前,所述方法还包括:
当所述第一序列号大于所述第二序列号时,所述目标接入网设备向所述终端设备发送所述第二数据包。
5.如权利要求4所述的方法,其特征在于,所述方法还包括:
所述目标接入网设备接收所述第一消息;
所述目标接入网设备从所述第一消息中获取所述用于传播多播数据的信息;
所述目标接入网设备发送第二消息,所述第二消息用于指示所述目标接入网设备上已建立的所述资源。
6.如权利要求4或5所述的方法,其特征在于,所述方法还包括:
所述目标接入网设备在本地缓存所述第一数据包,
其中,所述目标接入网设备向终端设备发送的所述第一数据包,包括:
所述目标接入网设备将本地缓存的所述第一数据包发送给终端设备。
7.如权利要求4或5所述的方法,其特征在于,所述方法还包括:
所述目标接入网设备根据所述第一序列号和所述第二序列号,确定将所述第一数据包发送给所述终端设备,
或者,
所述目标接入网设备根据所述第一序列号和所述第二序列号,确定将所述第二数据包发送给所述终端设备。
8.一种通信装置,其特征在于,包括:
处理器,用于执行存储器中存储的计算机程序,以使得所述通信装置执行如权利要求1至3中任一项所述的方法。
9.一种计算机存储介质,其特征在于,其上存储有计算机程序,所述计算机程序被计算机执行时,以使得实现如权利要求1至3中任一项所述的方法。
10.一种通信***,其特征在于,包括:
目标接入网设备和源接入网设备,
其中,所述目标接入网设备用于执行:如权利要求1至3中任一项所述的方法,所述源接入网设备用于执行:如权利要求4所述的方法。
11. 一种计算机程序产品,其特征在于,所述计算机程序产品在计算机上执行时,使得所述计算机执行如权利要求 1 至3中任一项所述的方法。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2020/077375 WO2021174377A1 (zh) | 2020-03-01 | 2020-03-01 | 切换方法和通信装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115136651A CN115136651A (zh) | 2022-09-30 |
CN115136651B true CN115136651B (zh) | 2024-06-11 |
Family
ID=77614436
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202080097000.1A Active CN115136651B (zh) | 2020-03-01 | 2020-03-01 | 切换方法和通信装置 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20220408317A1 (zh) |
EP (1) | EP4099760A4 (zh) |
CN (1) | CN115136651B (zh) |
WO (1) | WO2021174377A1 (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113498132B (zh) * | 2020-04-03 | 2022-09-20 | 维沃移动通信有限公司 | 移动性管理方法、源基站、目标基站及终端设备 |
WO2021098123A1 (en) | 2020-04-08 | 2021-05-27 | Zte Corporation | Multicast and broadcast service continuity during mobility |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109842639A (zh) * | 2017-11-24 | 2019-06-04 | 华为技术有限公司 | 实现切换过程中业务连续性的方法、设备及*** |
CN110167190A (zh) * | 2018-02-14 | 2019-08-23 | 华为技术有限公司 | 会话建立方法和设备 |
WO2019165427A1 (en) * | 2018-02-26 | 2019-08-29 | Qualcomm Incorporated | User plane function (upf) duplication based make before break handover |
WO2019223780A1 (en) * | 2018-05-25 | 2019-11-28 | Qualcomm Incorporated | Mixed mode multicast architecture |
CN110809299A (zh) * | 2019-11-07 | 2020-02-18 | 腾讯科技(深圳)有限公司 | 一种广播业务的模式切换方法以及相关装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5080644B2 (ja) * | 2007-06-18 | 2012-11-21 | エルジー エレクトロニクス インコーポレイティド | ハンドオーバ中のダウンリンクパケットデータコンバージェンスプロトコル動作 |
US10512004B2 (en) * | 2017-04-26 | 2019-12-17 | Motorola Mobility Llc | Indicating status of forwarded data |
-
2020
- 2020-03-01 CN CN202080097000.1A patent/CN115136651B/zh active Active
- 2020-03-01 WO PCT/CN2020/077375 patent/WO2021174377A1/zh unknown
- 2020-03-01 EP EP20922903.8A patent/EP4099760A4/en active Pending
-
2022
- 2022-08-26 US US17/896,920 patent/US20220408317A1/en active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109842639A (zh) * | 2017-11-24 | 2019-06-04 | 华为技术有限公司 | 实现切换过程中业务连续性的方法、设备及*** |
CN110167190A (zh) * | 2018-02-14 | 2019-08-23 | 华为技术有限公司 | 会话建立方法和设备 |
WO2019165427A1 (en) * | 2018-02-26 | 2019-08-29 | Qualcomm Incorporated | User plane function (upf) duplication based make before break handover |
WO2019223780A1 (en) * | 2018-05-25 | 2019-11-28 | Qualcomm Incorporated | Mixed mode multicast architecture |
CN110809299A (zh) * | 2019-11-07 | 2020-02-18 | 腾讯科技(深圳)有限公司 | 一种广播业务的模式切换方法以及相关装置 |
Non-Patent Citations (1)
Title |
---|
Ericsson.S2-186420 "Anchor change for Ethernet PDU Sessions".3GPP tsg_sa\wg2_arch.2018,(第tsgs2_128_vilnius期),第1-4页. * |
Also Published As
Publication number | Publication date |
---|---|
WO2021174377A1 (zh) | 2021-09-10 |
US20220408317A1 (en) | 2022-12-22 |
EP4099760A1 (en) | 2022-12-07 |
CN115136651A (zh) | 2022-09-30 |
EP4099760A4 (en) | 2023-04-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10973000B2 (en) | Message sending method and apparatus | |
EP3927107B1 (en) | Method for establishing a fronthaul interface and base station | |
CN114503776A (zh) | 使用共享下行链路数据支持群组通信 | |
US11811670B2 (en) | Packet delay parameter obtaining method, system, and apparatus | |
CN113973322B (zh) | 一种通信方法及装置 | |
US10728946B2 (en) | System information handling for dual connectivity cellular systems | |
CN112636884B (zh) | 一种消息传输方法和装置 | |
WO2017024909A1 (zh) | 一种进行数据传输的方法和设备 | |
EP4171074A1 (en) | Communication method and communication apparatus | |
US20220408317A1 (en) | Handover method and communication apparatus | |
WO2020206582A1 (zh) | 一种用于中继通信的方法和装置 | |
WO2022017285A1 (zh) | 报文转发方法、装置及*** | |
US20230370902A1 (en) | Relay UE Selection for Transmission Over Sidelink | |
WO2021140464A1 (en) | TSC-5G QoS MAPPING WITH CONSIDERATION OF ASSISTANCE TRAFFIC INFORMATION AND PCC RULES FOR TSC TRAFFIC MAPPING AND 5G QoS FLOWS BINDING | |
WO2019214733A1 (zh) | 一种通信方法及装置 | |
US20230370948A1 (en) | Method and Apparatus for Path Switch | |
WO2021097858A1 (zh) | 一种通信方法及装置 | |
CN112970284B (zh) | 使用多个分组数据单元会话的超可靠通信 | |
WO2023284551A1 (zh) | 通信方法、装置和*** | |
CN113645572B (zh) | 一种通信方法、装置及存储介质 | |
WO2022082690A1 (zh) | 群组切换的方法、装置和*** | |
CN115734170A (zh) | 一种组播/广播会话管理方法及通信装置 | |
WO2023197184A1 (zh) | Iab宿主设备以及传输地址配置方法 | |
WO2014000611A1 (zh) | 传输数据的方法和装置 | |
WO2024026803A1 (zh) | 移动节点的配置方法和宿主设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |