CN114788392B

CN114788392B - Operator network identification in network sharing

Info

Publication number: CN114788392B
Application number: CN201980102886.1A
Authority: CN
Inventors: A·阿乔纳; S·钱德拉舍卡; P·H·诺瓦克; 茹黎涛
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2019-12-13
Filing date: 2019-12-13
Publication date: 2024-11-19
Anticipated expiration: 2039-12-13
Also published as: CN114788392A; WO2021114285A1

Abstract

Example embodiments of the present application relate to operator network identification. According to some example embodiments, a first apparatus included in a second network device obtains, from a first network device, a first identification of a first operator network for determining a service termination point associated with a terminal device. The second network device is configured to provide dual connectivity with the first network device to the terminal device. The first apparatus determines a second operator network for serving the terminal device through the second network device, and transmits information about a first identity of the first operator network and a second identity of the second operator to the second apparatus included in the second network device. By this scheme, it is possible to distinguish operator networks selected by different network devices within a network device having a split architecture in a dual connection scenario.

Description

Operator network identification in network sharing

Technical Field

Embodiments of the present application relate generally to the field of telecommunications and, more particularly, relate to a method, apparatus, device, and computer-readable storage medium for carrier network identification.

Background

With the development of communication systems, new technologies are proposed. Next generation communication systems are expected to support accommodating explosive data traffic, greatly increased transmission rates per user, significantly increased numbers of connected devices, very low end-to-end latency, and energy efficiency. For this reason, various techniques have been developed.

Traditionally, each operator provides its own core network and its own Radio Access Network (RAN) to provide access to the operator's core network. However, deployment of the network requires high effort and cost. Thus, a network sharing architecture is proposed that allows different operators to share a common network, thereby sharing network resources according to agreed allocation schemes. Identification of networks for different operators is important in a network sharing architecture.

Disclosure of Invention

In general, example embodiments of the present application provide solutions for operator network identification.

In a first aspect, a first apparatus is provided. The first device includes at least one processor; and at least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first apparatus to obtain, from a first network device, a first identification of a first operator network for determining a service termination point associated with a terminal device, the first apparatus being included in a second network device, and the second network device being configured to provide dual connectivity with the first network device to the terminal device; determining a second operator network for serving the terminal device through the second network device; and transmitting information about the first identity of the first operator network and the second identity of the second operator network to a second apparatus comprised in the second network device.

In a second aspect, a second apparatus is provided. The first device includes at least one processor; and at least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to receive information regarding a first identity of a first operator network and a second identity of a second operator network from a first device contained in a second network device, the second device contained in the second network device, and the second network device configured to provide dual connectivity with the first network device to a terminal device; identifying an end point of a service associated with the terminal device based on the first identification; and identifying a second operator network for providing services to the terminal device through the second network device based on the second identification.

In a third aspect, a network device is provided. The network device comprises a first network entity configured to: obtaining, from another network device, a first identity of a first operator network for determining a service termination point associated with a terminal device, wherein the network device is configured to provide dual connectivity with the other network device to the terminal device, determine a second operator network for serving the terminal device through the second network device, and provide information regarding the first identity of the first operator network and the second identity of the second operator network; and a second network entity communicatively coupled to the first network entity and configured to obtain information about the first and second identities from the first network entity.

In a fourth aspect, a method is provided. The method comprises the following steps: at a first apparatus comprised in a second network device, obtaining from a first network device a first identity of a first operator network for determining a service termination point associated with a terminal device, and the second network device being configured to provide dual connectivity with the first network device to the terminal device; determining a second operator network for serving the terminal device through the second network device; and transmitting information about the first identity of the first operator network and the second identity of the second operator network to a second apparatus comprised in the second network device.

In a fifth aspect, a method is provided. The method comprises the following steps: at the second apparatus, and receiving information from the first apparatus regarding a first identity of the first operator network and a second identity of the second operator network, the first and second apparatuses being contained in a second network device, and the second network device being configured to provide dual connectivity with the first network device for the terminal device; identifying a service termination point associated with the terminal device based on the first identification; and identifying the second operator network serving the terminal device through the second network device based on the second identification.

In a sixth aspect, a first device is provided. The first device comprises means for: obtaining, from a first network device, a first identification of a first operator network for determining a service termination point associated with a terminal device, the first device being comprised in a second network device, and the second network device being configured to provide dual connectivity with the first network device to the terminal device; determining a second operator network for serving the terminal device through the second network device; and transmitting information about the first identity of the first operator network and the second identity of the second operator network to a second device included in the second network device.

In a seventh aspect, a second device is provided. The second device comprises means for: receiving information from a first device regarding a first identity of a first operator network and a second identity of a second operator network, the first and second devices being comprised in the second network device, and the second network device being configured to provide dual connectivity with the first network device for a terminal device; identifying a service termination point associated with the terminal device based on the first identification; and identifying the second operator network serving the terminal device through the second network device based on the second identification.

In an eighth aspect, an apparatus is provided. The apparatus comprises the first apparatus of the sixth aspect described above and the second apparatus of the seventh aspect described above.

In a ninth aspect, a computer readable medium is provided. The computer readable medium comprises program instructions for causing an apparatus to perform a method according to at least any one of the fourth and fifth aspects described above.

It is to be understood that the abstract section is not intended to identify key or essential features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

Some example embodiments will now be described with reference to the accompanying drawings, in which:

FIG. 1 illustrates an example communication environment in which example embodiments of the present application may be implemented;

FIG. 2 illustrates a block diagram of an example network device having an exploded architecture;

Fig. 3 illustrates a signaling flow for operator network identification according to some example embodiments of the present application;

fig. 4 illustrates a signaling flow for transmitting a context management message according to some example embodiments of the present application;

Fig. 5 illustrates a signaling flow for transmitting a context management message according to some further example embodiments of the present application;

FIG. 6 illustrates a flowchart of a method implemented on a first device according to some example embodiments of the application;

FIG. 7 shows a flowchart of a method implemented on a second device according to some other example embodiments of the application;

FIG. 8 shows a simplified block diagram of an apparatus suitable for practicing the exemplary embodiments of this application; and

FIG. 9 illustrates a block diagram of an example computer-readable medium, according to some example embodiments of the application.

The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements.

Detailed Description

The principles of the present application will now be described with reference to some example embodiments. It should be understood that these examples are presented for the purpose of illustration only and to aid one skilled in the art in understanding and practicing the application and are not meant to limit the scope of the application in any way. The embodiments described herein may be implemented in various ways other than those described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs.

References in the present disclosure to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. In addition, these terms do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It will be understood that, although the terms "first" and "second" may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and/or" includes any and all combinations of one or more of the listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes," "including," "having," "includes" and/or "including," when used herein, specify the presence of stated features, elements, and/or components, but do not preclude the presence or addition of one or more other features, elements, components, and/or groups thereof.

As used in this disclosure, the term "circuit" may refer to one or more or all of the following:

(a) Hardware-only circuit implementations (e.g., implementations in analog and/or digital circuits only); and

(B) A combination of hardware circuitry and software, for example (applicable):

(i) Combination of analog and/or digital hardware circuitry and software/firmware, and

(Ii) Any portion of the hardware processor(s) with software (including digital signal processor), software, and memory(s) that work together to cause a device (e.g., mobile phone or server) to perform various functions; and

(C) Hardware circuit(s) and/or processor(s), such as microprocessor(s) or portion of microprocessor(s), that require software (e.g., firmware) for operation, software may not be present when operation is not required.

This definition of circuit applies to all uses of this term in this application, including in any claims. As another example, as used in this disclosure, the term circuitry also encompasses hardware-only circuitry or processor (or multiple processors) or an implementation of a hardware circuit or portion of a processor and its (or their) accompanying software and/or firmware. For example, if applicable to the particular claim element, the term circuitry also encompasses a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, a cellular network device, or other computing or network device.

As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as new air interface (NR), long Term Evolution (LTE), LTE-advanced (LTE-a), wideband Code Division Multiple Access (WCDMA), high Speed Packet Access (HSPA), narrowband internet of things (NB-IoT), and the like. Furthermore, the communication between the terminal device and the network device in the communication network may be performed according to any suitable several generation communication protocols, including, but not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, future fifth generation (5G) communication protocols, and/or any other protocols currently known or to be developed in the future. Embodiments of the present application may be applied in various communication systems. In view of the rapid development of communications, there are of course also future types of communication technologies and systems in which the present application may be implemented. The scope of the application should not be considered limited to the system described above.

As used herein, the term "network device" refers to a node in a communication network through which terminal devices access the network and receive services therefrom. The network devices may refer to Base Stations (BSs) or Access Points (APs), such as node BS (nodebs or NB), evolved nodebs (eNodeB or eNB), NR NB (also known as gNB), remote Radio Units (RRU), radio Heads (RH), remote Radio Heads (RRH), relays, low power nodes (e.g., femto, pico base stations), non-terrestrial networks (NTNs) or non-terrestrial network devices, such as satellite network devices, low Earth Orbit (LEO) satellites, and Geosynchronous Earth Orbit (GEO) satellites, aircraft network devices, etc., depending on the terminology and technology applied.

The term "terminal device" refers to any terminal device capable of wireless communication. By way of example, and not limitation, a terminal device may also be referred to as a communication device, a User Equipment (UE), a Subscriber Station (SS), a portable subscriber station, a Mobile Station (MS), or an Access Terminal (AT). The terminal devices may include, but are not limited to, mobile phones, cellular phones, smart phones, voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal Digital Assistants (PDAs), portable computers, desktop computers, image capture terminal devices (e.g., digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, computer embedded devices (LEEs), laptop devices (LMEs), USB dongles, smart devices, wireless client devices (CPE), internet of things (loT) devices, watches or other wearable devices, head Mounted Displays (HMDs), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronics devices, devices operating on commercial and/or industrial wireless networks, and the like. In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

Example Environment and principles of operation

With the development of telecommunications, it has been proposed to support network sharing between different operators. The network sharing architecture should allow multiple participating operators to share one or more public networks and their resources according to a contracted allocation scheme. The shared network includes a Radio Access Network (RAN). The shared resources include radio resources. Network sharing is one way for operators to share the heavy deployment costs of a transport network. In addition to this shared RAN, the operator may or may not have an additional dedicated radio access network.

RAN sharing may be implemented through two standardized architectures. The first architecture is called Mobile Operator Core Network (MOCN) and consists of different participating operators that connect their Core Network (CN) infrastructure to a commonly shared RAN. In this case, each participating operator may run CN-RAN procedures from its own managed RAN. In the MOCN architecture, the RAN routes an initial access of the UE to the shared network to one of the available CN nodes. The supported UE should inform the RAN of the selected core network operator so that the RAN can route properly. The second architecture option is called gateway core network (GWCN) and it includes a shared RAN connected to a single shared CN. Thus, participating operators will share the CN as well as the RAN.

FIG. 1 illustrates an example communication environment 100 for network sharing in which example embodiments of the application may be implemented. In the example of fig. 1, the core network 110-1 and the core network 110-2 are provided and operated by two different operators (i.e., a first operator and a second operator). The operator can be identified by a corresponding identification. In one example, the different operators are identified by respective Public Land Mobile Network (PLMN) identities. Thus, as an example, a first operator of the core network 110-1 may be identified by identifying "PLMN ID1", while a second operator of the core network 110-2 may be identified by identifying "PLMN ID 2".

In a network sharing scenario, the RAN is shared by two operators. As shown, a network device 120-1, which is an access node of the RAN, is connected to both core networks 100-1, 110-2, e.g., to one or more core network entities via an S1-U interface. Another network device 120-2 is also connected to both core networks 100-1, 110-2, e.g. to one or more core network entities via an S1-U interface. In such an architecture, two core networks 100-1, 110-2 may share radio resources in network device 120-1 and network device 120-2.

In some example embodiments, core network 110-3 also shares network device 120-2. For example, the core network 110-3 is also provided and operated by the same second operator of the core network 110-2, and thus may be identified by the identity of the second operator. In some example embodiments, there may be one or more network devices that are not shared by different operators. For example, the network device 120-3 is only connected to the core network 110-3 of the second operator.

Core networks 110-1, 110-2, and 110-3 are collectively or individually referred to herein as core network 110, and network devices 120-1, 120-2, and 120-3 are collectively or individually referred to herein as network device 120. In the example shown in fig. 1, the network of the first operator (also referred to as a "first operator network") may include a core network 110-1, a network device 120-1, and a network device 120-1. The second operator's network (also referred to as a "second operator network") may include core network 110-2, core network 110-3, and network devices 120-1 through 120-3. The network devices 120-1 and 120-2 (and their access resources in the respective RANs) are shared by the first and second operators. In this example, two operators (e.g., identified by PLMN ID1 and PLMN ID 2) share Radio Resource Management (RRM) resources and a transport network for the X2 interface. Network device 120-1 may be a 4G eNB and network device 120-2 may be a 5G nb. In this case, the two PLMNs share resources in the 4G eNB and the 5G nb. In this example, the operators do not share a core network and each PLMN has its own core network to which the enbs/gnbs need to be connected separately.

In some example embodiments, one or more of the network devices 120 may be implemented in a split architecture, where different individual logical network entities are configured to handle respective functions. The gNB in NR is one example of such a network device, which may be implemented in a split architecture.

Fig. 2 shows an example of a network device 120 with an exploded architecture. As shown, network device 120 is comprised of a plurality of network entities including a central unit control plane (CU-CP) 210, one or more central unit user planes (CU-UP) 220-1, 220-2, collectively or individually referred to as CU-UP 220, where N is an integer equal to or greater than one, and one or more Distributed Units (DU) 230-1, collectively or individually referred to as DU 230, where M is an integer equal to or greater than 1. In examples where network device 120 is a gNB, CU-CP 210 may be referred to as a gNB-CU-CP, CU-UP 220 may be referred to as a gNB-CU-UP, and DU 230 may be referred to as a gNB-DU.

In some example embodiments, CU-CP 210 and CU-UP 220 collectively implement the functionality of a Central Unit (CU) of network device 120. In some example embodiments, CU-CP 210 is one logical node or entity that hosts the control plane portion of the Radio Resource Control (RRC) and Packet Data Convergence Protocol (PDCP) protocols for CUs of network device 120. CU-CP 210 may terminate an E1 interface connected to CU-UP 220 and an F1-C interface connected to DU 230. In some example embodiments, CU-UP 220 is a logical node or entity that hosts a user plane portion of the PDCP protocol for the CU of network device 120, as well as a user plane portion of the PDCP protocol and a Shared Device Access Protocol (SDAP) protocol for the CU of network device 120. CU-UP 220 can terminate at an E1 interface that interfaces with CU-CP 210 and an F1-U interface that interfaces with DU 230. In the example of fig. 2, control plane signaling may be performed by CU-CP 210 while user plane traffic is handled by CU-UP 220.

In some example embodiments, DU 230 is a logical node or entity that hosts the Radio Link Control (RLC), medium Access Control (MAC), and Physical (PHY) layers of network device 120 and whose operation is controlled in part by the CUs of network device 120. One DU 230 may support one or more cells. One cell may be supported by only one DU 230. DU 230 may terminate at an F1 interface that interfaces with the CU.

In the example shown in fig. 2, CU-CP and CU-UP in network device 120 are provided separately. In another split architecture, network device 120 may include a CU and one or more DUs 230. Together, CU-CP and CU-UP act as CU. In this example, a CU may be considered a logical node of RRC, SDAP, and/or PDCP protocols of network device 120 that hosts the operation of one or more DUs 230. A CU may terminate at an F1 interface connected to DU 230. It is understood that the network device 120 may be designed with any other split architecture.

In environment 100, terminal device 130 may communicate with one or more carrier networks via network devices. The terminal device 130 may support Dual Connectivity (DC), wherein the terminal device 130 maintains a Radio Resource Control (RRC) connection with a serving cell from a primary node (MN), and the terminal device 130 may be configured to have a connection to a Secondary Node (SN) for additional throughput. The MN and the SN are connected to each other by a backhaul interface, such as an X2-U interface, an X2-C interface, an Xn-U interface, and/or an Xn-C interface. In the example of fig. 1, terminal device 130 is connected to network device 120-1 and network device 120-2. Network device 120-1 may act as a MN and network device 120-2 may act as a SN for terminal device 130 in DC.

Different DC options may be applied to the terminal device 130. One option may include an evolved UMTS terrestrial radio access network (E-UTRAN) -NR DC (EN-DC) mode in which the MN for terminal device 130 is an eNB (e.g., network device 120-1 is an eNB) and the SN for terminal device 130 is an NR gNB (e.g., network device 120-2 is a gNB). The EN-DC mode is a specific example of multi-RAT DC (MR-DC) supported by the terminal device 130. Another DC option may include NR DC where terminal device 130 is connected to an NR gNB acting as a MN and another NR gNB acting as an SN (i.e., network devices 110-1 and 110-2 are both gnbs). In DC, at least the MN is connected to an operator network. In some example embodiments, the SN may also be connected to an operator network.

It should be understood that the number of devices and networks and their connections are for illustration purposes only and are not meant to be limiting in any way. Environment 100 may include any suitable number of devices and networks suitable for implementing embodiments of the present application.

Communication in communication environment 100 may be implemented in accordance with any suitable communication protocols including, but not limited to, first generation (1G), second generation (2G), third generation (3G), fourth generation (4G), fifth generation (5G), etc. cellular communication protocols, as well as wireless local area network communication protocols, such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, etc., and/or any other protocols currently known or developed in the future. Further, the communication may utilize any suitable wireless communication technology including, but not limited to: code Division Multiple Access (CDMA), frequency Division Multiple Access (FDMA), time Division Multiple Access (TDMA), frequency Division Duplex (FDD), time Division Duplex (TDD), multiple Input Multiple Output (MIMO), orthogonal Frequency Division Multiplexing (OFDM), discrete fourier transform spread OFDM (DFT-s-OFDM), and/or any other technique now known or later developed.

In a communication environment where network sharing is deployed, if one or more network devices are in a disaggregated architecture, there may be some communication scenarios where conflicting and inconsistent behavior occurs due to lack of appropriate means to consistently and correctly identify carrier identities between different logical entities of the network devices. Conflict and inconsistent behavior is particularly urgent in DC.

In the DC scenario, the MN for the terminal device in the DC indicates to the SN the identity of the operator network for determining the termination point of the traffic communication. In this way, the SN can know from which operator network the traffic needs to traverse. The identity of the operator network is typically matched to the core network used in the MN. Thus, the MN can signal to the SN the S1-U termination point to the core network selected and used by the MN.

On the SN side, the main problem is that only one identity of the operator network is currently allowed to signal between different network entities in the disaggregated architecture of the SN, e.g. signaling over the F1 and E1 interfaces. Thus, in case the SN is a network device shared by different operator networks, it would be beneficial in practice to be limited to follow the operator network selected by the MN, and then to signal the identity of the operator network selected by the MN between its network entities, even if the SN is allowed to select the operator network by itself. This limitation causes problems because in many cases the operator network indicated by the MN should not be used to count traffic at the SN, but only to indicate the end point to which the SN needs to transmit the traffic. Thus, erroneous statistics and user billing may result when the traffic of the terminal device is marked as belonging to an incorrect operator network by the identification signalled by the transmission signal of the operator network. Also, the SN is not free to select the correct identity of the appropriate operator network and all user traffic must be considered as belonging to the operator network originally selected by the MN.

There are other problems. For example, if there is a list of equivalent operator networks, the SN (e.g., DU of the SN) may be able to select the best cell from any equivalent operator network during terminal device handoff. But unless the backhaul of these operator networks (e.g., core networks) are also shared, selecting an equivalent operator network instead of the network selected by the MN would result in inconsistent resource sharing because the operator networks for cell selection and resource selection are inconsistent or not closely related.

To avoid at least some of the potential problems described above, in one possible implementation, the SN is not allowed to perform the selection of the operator network, but rather reuses the identity of the same operator network selected by the MN to ensure that traffic is directed to the correct termination point in the dual connectivity. With this embodiment, in the case of an exploded architecture for the SN gNB, the gNB-CU-CP always reuses the PLMN ID provided by the MN when the UE/bearer context is established through F1 (pointing to the gNB-DU) and through E1 (pointing to the gNB-CU-UP). However, this is undesirable because it artificially imposes restrictions at the SN to prohibit the SN from freely selecting the identity corresponding to the appropriate operator, and also forces the SN to treat all user traffic as belonging to the PLMN originally selected by the MN, as mentioned above.

In summary, the lack of appropriate operator network identification results in some problems having to be circumvented, even in some scenarios violating the principles of network sharing. Furthermore, interoperability problems may occur in inter-operator scenarios due to lack of consistency in behavior and incorrect statistics and billing leading to wrong operator networks.

According to some example embodiments of the present application, an improved solution for operator network identification is provided. In this scenario, multiple identities of the operator network may be transmitted between different devices or network entities within the network device. In particular, the first network device and the second network device are configured to provide dual connectivity to the terminal device, and the first network device sends a first identification of a first operator network to the second network device for determining a service termination point associated with the terminal device. The first means or network entity of the second network device may determine a second operator network for serving the terminal device through the second network device. The first apparatus or network entity of the second network device then transmits the first identification of the first operator network obtained from the first network device and the second identification of the second operator network determined by the second network device to the second apparatus or network entity of the second network device.

By this approach, by transmitting the identities of multiple operator networks, operator networks selected by different network devices can be distinguished within a network device using a split architecture in a DC scenario. When acting as an SN in a dual connection, the network device may direct traffic to the correct termination point (e.g., X2-U or S1-U) while maintaining autonomy to select and identify the appropriate operator network for resource scheduling, thereby resolving conflicts with traffic termination and avoiding erroneous traffic statistics.

Exemplary embodiments of the present application will be described in detail below with reference to the accompanying drawings. It should be appreciated that while some example embodiments of the application are described below in a network sharing architecture, the application may be implemented in other network architectures, such as those without network sharing.

Example signaling flow

Referring now to fig. 3, a signaling flow 300 for operator network identification is shown according to some example embodiments of the application. For discussion purposes, the signaling flow 300 will be described with reference to fig. 1. The signaling flow 300 may involve a network entity 301 and a network entity 302, the network entity 301 and the network entity 302 being included in a network device having an exploded architecture, such as the network device 120-2 shown in fig. 1. In some example embodiments, the signaling flow 300 may also involve additional network devices, such as the network device 120-1 shown in fig. 1; and a terminal device, such as terminal device 130. It should be appreciated that signaling flow 300 may also be implemented in any other communication environment.

The network device 120-2 having the split architecture is configured to provide DC to the terminal device 130 along with the network device 120-1. Network device 120-1 may be a network device with or without a split architecture. For example, network device 120-2 may be a gNB and network device 120-1 may be an eNB or a gNB. Sometimes, for purposes of discussion, network device 120-1 may be referred to as a first network device and network device 120-2 may be referred to as a second network device. Terminal device 130 may be any terminal device (or UE) that supports a DC communication mode. The DC provided by the network devices 120-1, 120-2 may be any suitable DC.

The network entity 301 and the network entity 302 included in the network device 120-2 may be logical nodes or entities within the network device 120-2 that are communicatively coupled to each other and may signal at least an identity of an operator network therebetween. The network entity 301 herein may sometimes be referred to as a first network entity, while the network entity 302 herein may sometimes be referred to as a second network entity. In some example embodiments, network entity 302 may communicate with network entity 301 and be controlled by network entity 301 over an interface, such as a 3GPP defined interface (e.g., an E1 or F1 interface).

In an example where network device 120-2 is a gNB, network entities 301, 302 may be logical entities as shown in FIG. 2. Depending on the different signaling scenarios, the network entities 301, 302 may be different types of logical entities of the network device 120-2. For example, in some example embodiments, network entity 301 may be CU-CP 210 and network entity 302 may be CU-UP 220. In some example embodiments, network entity 301 may be a CU (i.e., a combination of CU-CP 210 and CU-UP 220), and network entity 302 may be DU 230. Some specific example signaling scenarios are discussed further below.

In the signaling flow 300, a network entity 301 comprised in the network device 120-2 obtains 305 a first identification of a first operator network for determining an end point of a service associated with the terminal device 130. In the case where the network device 120-1, 120-2 is to provide DC to the terminal device 130, the network device 120-1 may be a MN responsible for selecting an operator network for traffic communication with the terminal device 130, including backhaul traffic and user traffic communication. Accordingly, network device 120-2 may be an SN capable of facilitating traffic communications for terminal device 130. In some example embodiments, the network device 120-1 may communicate with the network device 120-2 over a backhaul interface (e.g., an X2-U interface, an X2-C interface, an Xn-U interface, and/or an Xn-C interface).

In some example embodiments, the first operator network selected by network device 120-1 may be associated with a particular operator (referred to as a "first operator"), which may be identified with an identification (i.e., a first identification). The first operator network may include a core network and a corresponding RAN that includes one or more network access nodes (including network device 120-1) to provide radio access. The first operator network selected by network device 120-1 to act as a MN may be matched to the core network used in network device 120-1. The first identification is used to indicate to the network device 120-2 to which operator network the traffic associated with the terminal device 130 needs to traverse from the network device 120-2. The network device 120-2 may select a correct address (e.g., a correct Internet Protocol (IP) address) to the first operator using the first identification. Thus, traffic associated with terminal device 130 may be directed to the correct termination point (e.g., over the X2-U/Xn-U interface, the X2-C/Xn-C interface, and/or the S1-U interface). Thus, the first operator network may be referred to as an operator network associated with an end point of a backhaul interface in the DC for the terminal device 130 (e.g., an operator network associated with an S1-U end point), and the first identification may be referred to as an end point identification.

In some example embodiments, the first operator network may be a PLMN and the first identity may be a PLMN identity. In some examples, the PLMN identification may be derived based on a combination of a Mobile Country Code (MCC) and a Mobile Network Code (MNC). It should be appreciated that other types of applicable operator networks are also possible. In some example embodiments, the network device 120-1 may transmit 310 (and then be acquired by the network entity 301) the first identification or information used to derive the first identification to the network device 120-1.

As a specific example, the network device 120-1 as a MN may serve the terminal device 130 in the first operator network, and the core network of the first operator network may maintain the context of the terminal device 130. If network device 120-1 decides to add network device 120-2 as an SN for terminal device 130, network device 120-1 may trigger an SN addition request to network device 120-2, e.g., over an X2-C/X2-U interface between the two network devices.

In an example embodiment of the application, rather than forcing network entity 301 of network device 120-2 to always reuse the first identity selected by network device 120-1, the entity is allowed to freely select an operator network device for resource scheduling by network device 120-2 without fear that conflicts and inconsistencies may occur in the operator network identities within network device 120-2. Network device 120-2 may be connected to multiple operator networks and the radio resources of network device 120-2 are shared by these operator networks. In this case, network device 120-2 may select some carrier network to serve terminal device 130, e.g., to provide access resources for communicating with terminal device 130 through network device 120-2. Thus, in the signaling flow 300, the network entity 301 determines 315 a second operator network for serving the terminal device 130 through the network device 120-2.

In some example embodiments, the second operator network selected by network device 120-1 may be associated with a particular operator (referred to as a "second operator"), which may be identified with an identification (i.e., a second identification). The second operator network may include a core network and a corresponding RAN that includes one or more network access nodes (including network device 120-2) to provide radio access. In some example embodiments, the network device 120-2 is shared by at least the first and second operators (if the two operators are different). Thus, the radio resources of network device 120-2 may be scheduled for communication associated with both operators, and network device 120-2 may need to correctly distinguish between the two operators and their operator networks, e.g., by their corresponding identities.

When a second operator network is selected for the terminal device 130 by the network device 120-2 for resource scheduling, the second operator network may be referred to as a service operator network that provides services to the terminal device 130 in the RAN of the network device 120-2 because the resources of the second operator network are scheduled for communication between the network device 120-2 and the terminal device 130. It should be noted that all terminations for the traffic of the terminal device 130 are still addressed to the first operator network selected by the network device 120-1 acting as MN.

In some example embodiments, the second operator network may be a PLMN and the second identity may be a PLMN identity. In some examples, the PLMN identification may be derived based on a combination of MCC and MNC. It should be appreciated that other types of applicable operator networks are also possible.

In some example embodiments, the network entity 301 may select the second operator network to be associated with the same operator as the first operator of the first operator network selected by the network device 120-1, or a different operator than the first operator. The network entity 301 may follow various criteria to select the second operator network as a different network than the first operator network. In some example embodiments, the network entity 301 may determine whether a cell allocated to the first operator network is available for the terminal device 130. The cell corresponds to a coverage area serviced by a network device shared by the first operator network. If no cell allocated to the first operator network is available, it may mean that the terminal device 130 is moving to a different area without the services of the first operator network, or that all cells allocated to the first operator network are overloaded. In this case, the network entity 301 may select or reselect the second operator network for the terminal device 130.

In some example embodiments, the second operator network may be selected from a list of equivalent operator networks for the first operator network. The network entity 301 may obtain the identity of the equivalent operator network list. The list may include a first operator network and one or more other operator networks equivalent to the first operator network. As used herein, an equivalent operator network of a first operator network may be considered equivalent to the first operator network in terms of operator network selection or reselection, cell selection or reselection, and handoff. The list of equivalent operator networks may be defined, for example, by the first operator. In some example embodiments, the list of equivalent operator networks may include a list of handoff restrictions. The network entity 301 may be able to select one of the equivalent operator networks in the list as the second operator network, e.g. in case no suitable cell of the first operator network is available.

Referring back to fig. 3, in case of the second operator network determination, the network entity 301 transmits 320 information about the first identity of the first operator network and the second identity of the second operator network to the network entity 302. The network entity 302 receives 325 information about the first and second entities from the network entity 301. The network entity 302 may thus identify 330 a service termination point (i.e. a termination point in a first operator network) associated with the terminal device 130 based on the first identification and identify 335 a second operator network for serving the terminal device 130 through the network device 120-2 based on the second identification.

In an example embodiment of the application, a first operator network selected by network device 120-1 for determining a service termination point associated with terminal device 130 may be distinguished from a second operator network selected by network device 120-2 for serving terminal device 130 through network device 120-2.

In some example embodiments, if the second operator network selected by network device 120-2 for serving terminal device 130 is different from the first operator network device selected by network device 120-1 for determining the service termination point, i.e., the second identity is different from the first identity, network entity 301 may transmit the first and second identities to network entity 302 in separate Information Elements (IEs). That is, the first and second identities have respective IEs for transmission. In some example embodiments, if the second identity is the same as the first identity, this means that the network device 120-2 still decides to reuse the first operator network to serve the terminal device 130, one of the first and second identities may be sent, for example, in its corresponding IE. Upon receiving such information, the network entity 302 may determine that the first identity and the second identity are the same.

In some example embodiments, in case the second operator network is different from the first operator network, by signaling a second identification of the second operator network to the network entity 302 responsible for managing the context associated with the terminal device 130, the network entity 302 may thus correctly identify the user traffic and the corresponding charging of the terminal device 130 as belonging to the correct second operator network based on the second identification. Furthermore, all traffic associated with terminal device 130 may still be directed to the correct termination point selected by network device 120-1. Furthermore, in some example embodiments of the application, the operator network identity may also be further evidence illustrating a possible roaming event in which the end point will need to be updated without affecting the operator network to which the service is marked as belonging (the second operator in some examples described above).

Example trigger for transmitting an identification

There are various triggers for transmitting information about the first and second identities from the network entity 301 to the network entity 302. In some example embodiments, the network entity 302 may be a logical unit of the network device 120-2 configured to manage (e.g., establish or modify) a context associated with the terminal device 130. For example, network entity 302 may be a CU-UP for managing bearer contexts associated with terminal device 130 or a DU for managing UE contexts associated with terminal device 130. In this case, if the network entity 301 determines to establish or modify a context associated with the terminal device 130, it may transmit information about the first and second identities to the network entity 302 in a context management message. In some example embodiments, the information regarding the first and second identities may be transmitted in a context setup request (e.g., a bearer context setup request or a UE context setup request) or in a context modification request (e.g., a bearer context modification request or a UE context modification request).

In some example embodiments, the network entity 302 may be capable of checking the compatibility of the operator networks when the context modification request (e.g., the bearer context modification request or the UE context modification request) receives the first and second identities of the first and second operator networks. In particular, the network entity 302 may determine whether the second operator network is compatible with the first operator network. The network entity 302 may modify a context (i.e., bearer or UE context) associated with the second operator network for the terminal device if the second operator network is compatible with the first operator network. Network entity 302 may send a context modification response to network entity 301 to indicate that the context has been modified. If the second operator network is not compatible with the first operator network, the network entity 302 may send a context modification response to the network entity 301 to reject the context modification request.

In some example embodiments, if the identity of the operator network used to determine the termination point changes, e.g., from a third identity of a third operator network to a first identity of a first operator network, the network entity 301 may transmit an IE corresponding to the first identity to the network entity 302 in a context modification request. Thus, network entity 302 may determine that the identity of the operator network for serving terminal device 130 through network device 120-2 remains unchanged (e.g., remains the second identity of the second operator network). The network entity 302 may still check the compatibility of the two operator networks.

Likewise, if the identity of the operator network used to serve the terminal device 130 through the network device 120-2 changes, for example, from the fourth identity of the fourth operator network to the first identity of the first operator network, the network entity 301 may transmit an IE corresponding to the first identity to the network entity 302 in a context modification request. Thus, the network entity 302 may determine that the identity of the operator network used to determine the termination point remains unchanged (e.g., remains the first identity of the first operator network). The network entity 302 may still check the compatibility of the two operator networks.

In an example where network entity 301 is CU-CP 210 of network device 120-2, it may be configured to send a bearer context establishment request or a bearer modification request containing the first and second identities to network entity 302, which network entity 302 may be CU-UP 220 of network device 120-2. Bearer context establishment requests or bearer modification requests may be sent from CU-CP 210 to CU-UP 220 through an interface (e.g., E1 interface) connected between them.

Since the legacy format of the bearer context setup request can only be used to indicate one identity of one operator network and the identity of the operator network is not transmitted in the bearer modification request, in some example embodiments, the format of the bearer context setup request or the bearer modification request may be extended to include two IEs for carrying the first and second identities in order to transmit information about the first and second identities. Thus, the E1 application protocol may be updated to specify the extended format of the bearer context setup request or the bearer modification request.

In one example, the bearer context setup request specified in 3gpp TS 38.463 (which is a specification related to the E1 application protocol) section 9.2.2.1 may be updated to include an IE for carrying the operator network identity as provided in table 1 below.

Table 1 example specification for IEs carrying identification

It is noted that the PLMN is an example operator network, the PLMN identity is an example identity of the operator network in table 1, and that the bearer context establishment request may contain one or more other IEs for carrying other information in addition to the IEs listed above. In this example, the IE "serving PLMN" (SERVING PLMN) is used to carry a second identity of the second operator network and the IE "end point PLMN ID" (Termination Point PLMN ID) is used to carry a first identity of the first operator network. If the presence of the IE "end point PLMN ID" in the bearer context establishment request is optional (denoted as "O"), this means that if the second identity of the second operator network (i.e. the identity of the serving PLMN) is the same as the first identity of the first operator network (i.e. the identity of the end point PLMN ID), the IE "end point PLMN ID" may not be specifically included in the request and the recipient of the request may have the identity of the serving PLMN as the identity of the end point PLMN. The presence of the IE "serving PLMN" is typically necessary (labeled "M" denotes mandatory) in order to establish the bearer context at the CU-UP. The IE "end point PLMN ID" is an additional IE to be added to the bearer context setup request. It should be understood that the name of the IE is only one example, and that other names are possible.

In one example, the bearer context modification request specified in 3gpp TS 38.463 section 9.2.2.4 may also be updated to include an IE for carrying the operator network identity as provided in table 2 below.

Table 2 example specifications for IEs carrying identities

It is noted that PLMN is one example operator network, PLMN identity is one example identity of an operator network in table 2, and that the bearer context modification request may contain one or more other IEs for carrying other information in addition to the IEs listed above. In this example, the presence of both the IE "serving PLMN" and the IE "end point PLMN ID" in the bearer context modification request is optional (denoted as "O"). If CU-CP 210 determines to change the serving PLMN for terminal device 130 to a new PLMN, e.g., when the terminal device experiences a cell handoff to a cell of the equivalent operator network, an IE "serving PLMN" may be included. If the network device 120-1 acting as the MN needs to update the termination point, e.g. in response to one or more roaming events, an IE "termination point PLMN ID" may be included. The IE "serving PLMN" and IE "end point PLMN ID" are additional IEs to be added to the bearer context modification request.

In an example where network entity 301 is a CU of network device 120-2 (a combination of CU-CP 210 and CU-UP 220), it may be configured to send a UE context setup request or a UE modification request containing the first and second identities to network entity 302, which network entity 302 may be DU 230 of network device 120-2. The UE context setup request or the UE modification request may be sent from the CU through an interface (e.g., F1 interface) connected between them.

Since the legacy format of the UE context setup request can only be used to indicate one identity of one operator network and no identity of the operator network is transmitted in the UE context modification request, in some example embodiments, the format of the UE context setup request or the UE context modification request may be extended to include two IEs for carrying the first and second identities in order to transmit information about the first and second identities. Thus, the F1 application protocol may be updated to specify the extended format of the UE context setup request or the UE modification request.

In one example, the UE context setup request specified in 3gpp TS 38.473 (which is a specification related to the F1 application protocol) section 9.2.2.1 may be updated to include an IE for carrying the operator network identity as provided in table 3 below.

Table 3 example specifications for IEs carrying identification

Note that PLMN is one example operator network, PLMN identity is one example identity of an operator network in table 3, and that the UE context setup request may contain one or more other IEs for carrying other information in addition to the IEs listed above. In this example, the presence of both the IE "serving PLMN" and the IE "end point PLMN ID" in the UE context setup request is optional (denoted as "O"). If CU-CP 210 determines to change the serving PLMN for terminal device 130 to a new PLMN, e.g., when the terminal device experiences a cell handoff to a cell of the equivalent operator network, an IE "serving PLMN" may be included. If the network device 120-1 acting as the MN needs to update the termination point, e.g. in response to one or more roaming events, an IE "termination point PLMN ID" may be included. The IE "end point PLMN ID" is an additional IE to be added to the UE context setup request. In one example, the UE context modification request specified in 3gpp TS 38.473, 9.2.2.7 th section may also be updated to include an IE for carrying the operator network identity as provided in table 4 below.

Table 4 example specifications for IEs carrying identification

It should be noted that PLMN is an example operator network, PLMN identity is an example identity of an operator network in table 4, and the UE context modification request may contain one or more other IEs for carrying other information in addition to the IEs listed above. In this example, the presence of both the IE "serving PLMN" and the IE "end point PLMN ID" in the UE context modification request is optional (denoted as "O") as in the UE context setup request. If the network device 120-1 acting as the MN needs to update the termination point, e.g. in response to one or more roaming events, an IE "termination point PLMN ID" may be included. The IE "serving PLMN" and the IE "end point PLMN ID" are additional IEs to be added to the UE context modification request.

It should be appreciated that some example updates to the bearer/UE context management message are described above. In other example embodiments, the bearer/UE context management message may be updated in other ways to indicate multiple identities of the operator network. The scope of the application is not limited in this respect.

The context management message may be transmitted from network entity 301 (which may be CU-CP 210 or CU) to network entity 302 (which may be CU-UP 220 or DU 230) during various possible procedures in network device 120-2 or network devices 120-1, 120-2 and possibly in terminal device 130 and network elements in the core network. Some example procedures include a procedure of adding an auxiliary gcb (SgNB) in EN-DC in which a UE context setup message is transmitted, and a bearer context setup procedure in which a bearer context setup request and a bearer context modification request are transmitted, and some procedures related to UE handover in which a UE/bearer context modification request is transmitted. To better understand the transmission of these context management messages, some example processes for message transmission are shown with reference to fig. 4-5.

Fig. 4 illustrates a signaling flow 400 for transmitting a UE context management message according to some example embodiments of the application. Signaling flow 400 may relate to network device 120-1 and network device 120-2 (more specifically, CU 402 is a combination of CU-CP 210 and CU-UP 220 and DU 230). Signaling flow 400 is related to SgNB addition procedures. Assume that network device 120-1 is an eNB, sometimes also referred to as a MeNB, acting as a MN in the DC of terminal device 130, and that network device 120-2 is a gNB. In this example, CU may be considered as network entity 301 in network device 120-2, and DU 230 may be considered as network entity 302 in network device 120-2.

Specifically, the network device 120-1, which is the MN of the terminal device 130, determines to add the network device 120-2 as the SN of the terminal device 130. Thus, network device 120-1 sends 405SgNB an add request to CU 402. In some example embodiments, sgNB add requests may carry a source cell group configuration (denoted "CG-ConfigInfo").

Upon receiving SgNB the add request message from network device 120-1, CU 402 sends 410 a UE context setup request message to DU 230 to establish the UE context. In some example embodiments, the UE context setup request message may include a first identification of a first operator network (e.g., PLMN ID 1) selected by network device 120-1 to determine an end point of traffic associated with terminal device 130 and a second identification of a second operator network (e.g., PLMN ID 2) selected by CU 402 to provide services to terminal device 130 through network device 120-2. In some example embodiments of the secondary node change, the UE context setup request message may contain a source cell group configuration to allow the DU 230 to perform incremental configuration.

DU 230 responds 415 to CU 402 with a UE context setup response message. Upon receiving the UE context setup request message, CU 402 responds 420 to network device 120-1 with SgNB an add request acknowledgement message. In some example embodiments, sgNB add request acknowledgement messages may carry the source cell group configuration.

It should be appreciated that SgNB addition procedures may include further signaling between network device 120-1, network entities within network device 120-1, and possibly terminal device 130, and one or more network elements in the core network. Such signaling is not shown here for simplicity.

Fig. 5 illustrates a signaling flow 500 for transmitting bearer context management messages according to some example embodiments of the application. The signaling flow 500 may involve network entities within the network device 120-2, including the CU-CP 210, the CU-UP 220, and the DU 230. The signaling flow 500 relates to the process of establishing a bearer context in the CU-UP 220. In this example, assume that network device 120-2 is a gNB. CU-CP 210 may be considered a network entity 301 in network device 120-2 and CU-UP 220 may be considered a network entity 302 in network device 120-2.

Specifically, bearer context establishment is triggered 505 in CU-CP 210 210 (e.g., after SgNB addition request message from network device 120-1). The CU-CP 210 sends 510 a bearer context setup request message to the CU-UP 220 to establish a bearer context in the CU-UP 220. In some example embodiments, the bearer context setup request message may include a first identification of a first operator network (e.g., PLMN ID 1) selected by network device 120-1 to determine an end point of traffic associated with terminal device 130 and a second identification of a second operator network (e.g., PLMN ID 1) selected by CU-CP 210 to provide services to terminal device 130 through network device 120-2.

The CU-UP 220 responds 515 to the CU-CP 210 with a bearer context setup response message. An F1 UE context setup procedure 520 is performed between CU-CP 210 and DU 230 to establish one or more bearers in DU 230.

The CU-CP 210 sends 525 a bearer context modification request message to the CU-UP 220. In some example embodiments, the bearer context modification request message may include a first identification of a first operator network (e.g., PLMN ID 1) selected by network device 120-1 for determining an end point of traffic associated with terminal device 130, and a second identification of a second operator network (e.g., PLMN ID 1) selected by CU-CP 210 for providing services to terminal device 130 through network device 120-2. The CU-UP 220 responds 530 to the CU-CP 210 with a bearer context modification response message.

In some example embodiments, uplink user data from terminal device 130 may be sent 535 from DU 230 to CU-UP 220, and downlink user data for terminal device 130 may be sent 540 from CU-UP 220 to DU 230.

It should be understood that the above-described process is shown only for illustrative purposes and is not meant to imply any limitation on the scope of the invention. The first and second identifications of the first and second operator networks may be notified from the network entity to another network entity within the network device 120-2 in various other processes.

Example methods implemented at respective devices

Fig. 6 shows a flowchart of an example method 600 implemented on a first device according to some example embodiments of the application. For discussion purposes, the method 600 will be described with reference to fig. 1-3 from the perspective of the network entity 301 (i.e., the first apparatus) included in the network device 120-2.

At block 610, the network entity 301 obtains a first identification of a first operator network from the network device 120-1 for determining an end point of a service associated with the terminal device 130. Network device 120-2 and network device 120-1 are configured to provide DC to terminal device 130. Network device 120-1 may be the one responsible for selecting the termination point and may be the MN in DC. The network device 120-2 may be a device that facilitates traffic communication for the terminal device 130 and may be an SN in DC.

At block 620, the network entity 301 determines a second operator network for serving the terminal device 130 through the network device 120-2. In an example embodiment of the application, as described above, the network entity 301 in the network device 120-2 is allowed to freely select the operator network for serving the terminal device 130. In some example embodiments, the second operator network may be the same operator network as the first operator network. In some example embodiments, the second operator network may be selected, for example, from a list of equivalent operator networks for the first operator network. In some example embodiments, the network entity 301 may determine whether a cell allocated to the first operator network is available for the terminal device 130. In case a cell is not available, the network entity 301 may select a second operator network equivalent to the first operator network, e.g. when a suitable cell allocated to the second operator is available.

At block 630, the network entity 301 transmits information regarding the first identity of the first operator network and the second identity of the second operator network to the network entity 302 in the network device 120-2. In this manner, network entity 302 may distinguish between the two operator networks and thus may properly identify the service termination point associated with terminal device 130 and the operator network that serves terminal device 130 through network device 120-2. Thus, traffic associated with the terminal device 130 may be properly directed to the end point, and the network entity 302 may also perform proper traffic statistics and charging for the terminal device 130 for services by the second operator network.

In some example embodiments, the information about the first and second identities may be transmitted in separate IEs, particularly if the second identity is different from the first identity. In some example embodiments, the information regarding the first and second identifications may be transmitted in a context setup request or a context modification request. For example, if network entity 301 is CU-CP 210 of network device 120-2 and network entity 302 is CU-UP 220 of network device 120-2, network entity 301 may send a bearer context setup request or a bearer context modification request to network entity 302 that includes information regarding the first and second identifications based on the actual event triggering transmission of the respective request.

As another example, if network entity 301 is a CU of network device 120-2 and network entity 302 is a DU 230 of network device 120-2, network entity 301 may send a UE context setup request or a UE context modification request containing information about the first and second identities to network entity 302 according to an actual event triggering transmission of the respective request.

Fig. 7 shows a flowchart of an example method 700 implemented at a second device according to some example embodiments of the application. For discussion purposes, the method 700 will be described with reference to fig. 1-3 from the perspective of the network entity 302 (i.e., the second apparatus) included in the network device 120-2.

At block 710, the network entity 302 receives information about a first identity of a first operator network and a second identity of a second operator network from the network entity 301 included in the network device 120-2. Network device 120-2 and other network devices, e.g., network device 120-1, are configured to provide DC to terminal device 130. In some example embodiments, the first identity and the second identity may be included in separate IEs transmitted from the network entity 301, in particular if the second identity is different from the first identity. In some example embodiments, the information regarding the first and second identifications may be sent in a context setup request or a context modification request.

The network entity 302 identifies a service termination point associated with the terminal device 130 based on the first identification at block 720 and identifies a second operator network for serving the terminal device 130 through the network device 120 based on the second identification at block 730.

In some example embodiments, if information regarding the first and second identities is included in the context modification request and the second identity is different from the first identity, the network entity 302 may check the compatibility of the carrier networks identified by the two identities in order to decide whether to accept or reject the context modification request. In particular, the network entity 302 may determine whether the second operator network is compatible with the first operator network. If the second operator network is compatible with the first operator network, the network entity 302 may modify a context associated with the second operator network for the terminal device 130. If the second operator network is not compatible with the first operator network, the network entity 302 may send a context modification response to the network entity 301 to reject the context modification request.

Example apparatus

In some example embodiments, a first device (e.g., network entity 301) capable of performing any of the methods 600 may include means for performing the respective operations of the methods 600. The device may be embodied in any suitable form. For example, the apparatus may be implemented in a circuit or a software module. The first device may be implemented as the network entity 301 or comprised in the network entity 301.

In some example embodiments, the first device comprises means for: obtaining, from a first network device (e.g., network device 120-1), a first identification of a first operator network for determining a service termination point associated with the terminal device, the first apparatus being included in a second network device (e.g., network device 120-2), and the second network device being configured to provide dual connectivity with the first network device to the terminal device; determining a second operator network for serving the terminal device through the second network device; and transmitting information regarding the first identity of the first operator network and the second identity of the second operator network to a second device included in the second network device (e.g., embodied as or included in the network entity 302).

In some example embodiments, the means for transmitting the information comprises means for: determining whether the second identity is different from the first identity; and in accordance with a determination that the second identity is different from the first identity, transmitting the first identity and the second identity to the second device as separate information elements.

In some example embodiments, the means for transmitting the information comprises: means for transmitting information about the first and second identities to the second device in a context setup request; or means for transmitting information about the first and second identities to the second device in a context modification request.

In some example embodiments, the means for determining the second operator network comprises means for: determining whether a cell allocated to the first operator network is available for the terminal device; and in accordance with a determination that the cell is not available, selecting a second operator network equivalent to the first operator network.

In some example embodiments, the first device comprises a central unit of the second network device, and the second device comprises a distributed unit of the second network device. In some example embodiments, the first device comprises a central unit control plane entity of the second network device, and the second device comprises a central unit user plane entity of the second network device.

In some example embodiments, the first device further includes means for performing other operations in some example embodiments of the method 600. In some example embodiments, the apparatus includes at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the first apparatus to perform operations.

In some example embodiments, a second device (e.g., network entity 302) capable of performing any of the methods 700 may include means for performing the respective operations of the methods 700. The device may be embodied in any suitable form. For example, the apparatus may be implemented in a circuit or a software module. The second device may be implemented as the network entity 302 or comprised in the network entity 302.

In some example embodiments, the second device comprises means for: receiving information about a first identity of a first operator network and a second identity of a second operator network from a first device (e.g., embodied as network entity 301 or means included in network entity 301), the first and second devices being included in a second network device, and the second network device being configured to provide dual connectivity with the first network device to a terminal device; identifying a service termination point associated with the terminal device based on the first identification; a second operator network for providing services to the terminal device through the second network device is identified based on the second identification.

In some example embodiments, the means for receiving information comprises means for receiving a first identity and a second identity from a first device in separate information elements, the first identity being different from the second identity.

In some example embodiments, an apparatus for receiving information includes: means for receiving information about the first and second identifications in a context setup request from the first device; or means for receiving information about the first and second identifications in a context modification request from the first device.

In some example embodiments, wherein information about the first and second identifications is included in the context modification request, the second device further comprises means for: determining whether the second operator network is compatible with the first operator network according to the determination that the second identifier is different from the first identifier; modifying a context associated with the second operator network for the terminal device in accordance with a determination that the second operator network is compatible with the first operator network; and sending a context modification response to the first device to reject the context modification request in accordance with a determination that the second operator network is not compatible with the first operator network.

In some example embodiments, the second device further includes means for performing other operations in some example embodiments of the method 700. In some example embodiments, the apparatus includes at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the second device to perform operations.

Example apparatus and computer-readable media

Fig. 8 is a simplified block diagram of an apparatus 800 suitable for use in practicing the exemplary embodiments of this application. Device 800 may be used to implement a communication device, such as network device 120 or terminal device 130 as shown in fig. 1, or network entity 301 or network entity 302 as shown in fig. 2. As shown, the device 800 includes one or more processors 810, one or more memories 820 coupled to the processors 810, and one or more communication modules 840 coupled to the processors 810.

The communication module 840 is used for two-way communication. The communication module 840 has one or more communication interfaces to facilitate communications with one or more other modules or devices. The communication interface may represent any interface required to communicate with other network elements. In some example embodiments, the communication module 840 may include at least one antenna.

The processor 810 may be of any type suitable to the local technology network and may include, as non-limiting examples, one or more of the following: general purpose computers, special purpose computers, microprocessors, digital Signal Processors (DSPs), and processors based on a multi-core processor architecture. The device 800 may have multiple processors, such as an application specific integrated circuit chip that is time-dependent on a clock synchronized to the host processor.

Memory 820 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memory include, but are not limited to, read-only memory (ROM) 824, electrically programmable read-only memory (EPROM), flash memory, a hard disk, a Compact Disk (CD), a Digital Video Disk (DVD), an optical disk, a laser disk, and other magnetic and/or optical storage. Examples of volatile memory include, but are not limited to, random Access Memory (RAM) 822 and other volatile memory that will not last during a power outage.

The computer program 830 includes computer-executable instructions that are executed by an associated processor 810. Program 830 may be stored in a memory such as ROM 824. Processor 810 may perform any suitable actions and processes by loading program 830 into RAM 822.

Example embodiments of the application may be implemented by program 830 so that device 800 may perform any of the processes of the disclosure discussed with reference to fig. 3-7. The exemplary embodiments of this application may also be implemented in hardware or by a combination of software and hardware.

In some example embodiments, the program 830 may be tangibly embodied in a computer-readable medium, which may be embodied in the device 800 (such as in the memory 820) or other storage device accessible to the device 800. Device 800 may load program 830 from a computer readable medium into RAM 822 for execution. The computer readable medium may include any type of tangible, non-volatile storage, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Fig. 9 shows an example of a computer readable medium 900 in the form of a CD or DVD. The computer readable medium has stored thereon a program 830.

In general, the various embodiments of the application may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor or other computing device. While various aspects of the embodiments of the application are illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present application also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product comprises computer executable instructions, such as instructions contained in program modules, which are executed in a device on a target real or virtual processor to perform any of the methods described above with reference to fig. 3-7. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within local or distributed devices. In distributed devices, program modules may be located in both local and remote memory storage media.

Program code for carrying out methods of the present application may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram block or blocks to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present application, computer program code or related data may be carried by any suitable carrier to enable an apparatus, device or processor to perform the various processes and operations described above. Examples of carriers include signals, computer readable media, and the like.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a computer-readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable reader read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Moreover, although operations are described in a particular order, this should not be construed as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Also, while the above discussion contains several specific implementation details, these should not be construed as limitations on the scope of the application, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the application has been described in language specific to structural features and/or methodological acts, it is to be understood that the application defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A second device for communication, comprising:

at least one processor; and

at least one memory including computer program code;

wherein the at least one memory and the computer program code are configured to, using at least one processor, cause the second device to:

receiving information about a first identifier of a first operator network and a second identifier of a second operator network from a first device included in a second network device, the second device being included in the second network device, and the second network device being configured to provide dual connectivity to a terminal device together with the first network device;

Identifying a service termination point associated with the terminal device based on the first identifier; and

identifying, based on the second identifier, the second operator network used to serve the terminal device through the second network device,

wherein the information about the first and second identifiers is included in a context modification request, and wherein the at least one memory and the computer program code are configured to, with the at least one processor, further cause the second apparatus to:

Determining whether the second operator network is compatible with the first operator network based on the determination that the second identifier is different from the first identifier;

modifying a context associated with the second operator network for the terminal device in accordance with a determination that the second operator network is compatible with the first operator network; and

Based on a determination that the second operator network is incompatible with the first operator network, a context modification response is sent to the first device to reject the context modification request.

2. The apparatus of claim 1, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to receive the information in the following manner:

The first identification and the second identification are received in separate information elements from the first device, the first identification being different from the second identification.

3. The apparatus according to claim 1 or 2, wherein the at least one memory and the computer program code are configured to, using the at least one processor, cause the second apparatus to receive the information in the following manner:

receiving information about the first and second identifiers in a context establishment request from the first device; or

Information about the first and second identifications is received in a context modification request from the first device.

4 . The apparatus according to claim 1 , wherein the first apparatus comprises a central unit of the second network device, and the second apparatus comprises a distributed unit of the second network device.

5. The apparatus according to claim 1 or 2, wherein the first apparatus comprises a central unit control plane entity of the second network device, and the second apparatus comprises a central unit user plane entity of the second network device.

6. A method for communication, comprising:

At the second device, receiving information about a first identifier of a first operator network and a second identifier of a second operator network from the first device, the first and second devices being included in a second network device, and the second network device being configured to provide dual connectivity to the terminal device together with the first network device;

identifying the second operator network serving the terminal device through the second network device based on the second identifier,

The information about the first and second identifiers is included in the context modification request, and the method further comprises:

7. The method of claim 6, wherein receiving the information comprises:

8. The method according to claim 6 or 7, wherein receiving the information comprises:

9. A second device for communication, comprising:

means for receiving information about a first identifier of a first operator network and a second identifier of a second operator network from a first device, the first and second devices being included in a second network device, and the second network device being configured to provide dual connectivity to a terminal device together with the first network device;

means for identifying a service termination point associated with the terminal device based on the first identifier; and

a device for identifying the second operator network serving the terminal device through the second network device based on the second identifier,

The information about the first and second identifiers is included in the context modification request, and the second device further includes means for:

Determining whether the second operator network is compatible with the first operator network according to the determination that the second identifier is different from the first identifier;

10. A computer-readable medium comprising program instructions, wherein the program instructions are used to cause a device to at least execute the method according to any one of claims 6 to 8.

11. A computer program product, comprising program instructions, wherein the program instructions are used to cause a device to at least execute the method according to any one of claims 6 to 8.