WO2015174018A1 - ネットワークノード及びシグナリング処理方法 - Google Patents
ネットワークノード及びシグナリング処理方法 Download PDFInfo
- Publication number
- WO2015174018A1 WO2015174018A1 PCT/JP2015/002134 JP2015002134W WO2015174018A1 WO 2015174018 A1 WO2015174018 A1 WO 2015174018A1 JP 2015002134 W JP2015002134 W JP 2015002134W WO 2015174018 A1 WO2015174018 A1 WO 2015174018A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- codec
- atgw
- sdp
- sdp offer
- supported
- Prior art date
Links
- 230000011664 signaling Effects 0.000 title claims description 98
- 238000003672 processing method Methods 0.000 title claims description 6
- 238000004891 communication Methods 0.000 claims abstract description 69
- 230000005540 biological transmission Effects 0.000 claims abstract description 13
- 238000004458 analytical method Methods 0.000 claims abstract description 12
- 238000013500 data storage Methods 0.000 claims abstract description 12
- 238000000034 method Methods 0.000 claims description 33
- 238000012546 transfer Methods 0.000 claims description 9
- 238000010295 mobile communication Methods 0.000 description 9
- 238000012545 processing Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 6
- 238000004873 anchoring Methods 0.000 description 4
- 238000013468 resource allocation Methods 0.000 description 3
- 230000003044 adaptive effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000011265 semifinished product Substances 0.000 description 1
- 238000004904 shortening Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1023—Media gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1023—Media gateways
- H04L65/103—Media gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- 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/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
- H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
- H04W36/00224—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
- H04W36/00226—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
Definitions
- the present disclosure relates to a network node used in a mobile communication scheme and a signaling processing method executed by the network node.
- VoIP Voice over Long Term Evolution
- VoLTE call the area where VoLTE service can be received is a limited area. Therefore, when going out of the VoLTE service area during a VoLTE voice call (hereinafter referred to as a VoLTE call), it is necessary to switch to a call using a conventional circuit switching system.
- SRVCC Single Radio Voice Call Continuity
- FIG. 1 shows part of a 3GPP mobile communication network configuration.
- the mobile communication network shown in FIG. 1 is e-UTRAN (evolved Universal Terrestrial Radio Access Network), e-UTRAN base station (e-node B), PS network, CS network, CS network base station subsystem, non-patent document 2, IMS (IP Multimedia Subsystem) described in Non-Patent Document 3.
- e-UTRAN is a radio access network capable of providing VoLTE service.
- the PS network provides a VoLTE service, and includes a packet data network gateway (P-GW), a serving gateway (S-GW), and a mobility management entity (MME).
- the CS network is composed of a mobile switching center (MSC) and a media gate way (MGW).
- the base station subsystem of the CS network comprises an RNC (Radio Network Controller) and a nodeB.
- the IMS performs call control and the like, and includes a CSCF (Call Session Control Function) and an SCC AS (Service Centralization and Continuity Application Server).
- MSC and MGW are represented as one node (MSC / MGW 110) in FIG. 1 and FIG. 2, they may be represented as separate nodes.
- FIG. 1 it is assumed that UE 100 and UE 102, which are mobile communication terminals (UE: User Equipment), are initially connected to the PS network (however, the radio access network, base station and PS network on UE 102 side are not shown). ).
- UE 100 and UE 102 start a call, a session setup process is performed. That is, by transmitting / receiving an offer / answer of SDP (Session Description Protocol) by signaling of IMS between the UE 100 and the UE 102, a codec and the like used in a call are negotiated.
- FIG. 5 shows an example of IMS signaling transmission / reception at the time of session setup. IMS signaling is transmitted and received (not shown in FIG.
- FIG. 6 shows an example of the SDP offer / answer.
- AMR and AMR-WB described later are offered, and AMR is selected by an answer.
- HO Hand Over
- Path A, Path B, and Path C indicated by solid lines in FIG. 1 indicate paths through which call data passes.
- reference numerals 200, 202, 204 and 206 indicated by broken lines in FIG. 1 indicate paths through which signaling in SRVCC handover processing passes.
- FIG. 2 is a sequence chart showing an operation of SRVCC handover processing.
- the UE 100 and the UE 102 are initially connected to the PS network (e-UTRAN), respectively, and the call data between the UE 100 and the UE 102 is transmitted and received through the Path A.
- the e-node B detects this and exchanges core network signaling (hereinafter referred to as signaling) with the RNC / node B via the MME, MSC / MGW 110 Signaling 200 shown in Fig. 1. Steps (hereinafter "ST") 200 shown in Fig. 2).
- signaling core network signaling
- a data path in the CS network is prepared between node B and MSC / MGW 110, and when the preparation is completed, MME instructs UE 100 to hand over to UTRAN (CS network) via e-node B. Is issued.
- MSC / MGW 110 exchanges signaling of IMS (hereinafter IMS signaling) with UE 102 via CSCF / SCC AS of the UE 100's own network (signaling 202 shown in FIG. 1; ST 202 shown in FIG. 2).
- IMS signaling signaling of IMS
- UE 102 via CSCF / SCC AS of the UE 100's own network
- an instruction is issued to switch the transmission / reception destination of the call data of the UE 102 from the UE 100 to the MSC / MGW 110, and the Path B is established.
- the UE 100 exchanges signaling with the MSC / MGW 110 via the RNC / node B (signaling 204 shown in FIG. 1; ST 204 shown in FIG. 2). This establishes Path C.
- Path C After Path C is established, the MSC / MGW 110 exchanges signaling with the P-GW / S-GW via the MME (signaling 206 shown in FIG. 1; ST 206 shown in FIG. 2). Thus, Path A is deleted.
- SRVCC enhanced-SRVCC
- ATCF Access Transfer Control Function
- FIG. 3 shows part of a 3GPP mobile communication network configuration that enables eSRVCC. Similar to FIG. 1, the mobile communication network shown in FIG. 3 is composed of an e-UTRAN, an e-node B, a PS network, a CS network, a base station subsystem of the CS network, and an IMS.
- IMS in addition to CSCF and SCC AS, there are ATCF (Access Transfer Control Function) and ATGW (Access Transfer GateWay).
- FIG. 3 and FIG. 4 show ATCF and ATGW as one node (ATCF / ATGW 320), they may be shown as separate nodes.
- the UE 100 and the UE 102 are initially connected to the PS network (however, the radio access network on the UE 102 side, the base station and the PS network are not shown). That is, it is assumed that a VoLTE call is being performed between the UE 100 and the UE 102. At this time, it is assumed that the UE 100 performs handover (HO: Hand Over) to the CS network in the middle of a call.
- HO Hand Over
- Path A, Path B, Path C, and Path D indicated by solid lines in FIG. 3 indicate paths through which call data passes.
- 300, 302, 304 and 306, which are indicated by broken lines in FIG. 3, indicate paths through which signaling in the eSR VCC handover process and IMS signaling pass.
- FIG. 4 is a sequence chart showing an operation of eSRVCC handover.
- the UE 100 and the UE 102 are initially connected to the PS network (e-UTRAN) respectively.
- ATCF anchors IMS signaling in ATCF / ATGW 320, and ATGW anchors call data that is, at the start of a call between UE 100 and UE 102, the IMS signaling of the start of the call is relayed by the ATCF of the network (the visited network) to which the UE is connected, and the ATCF needs an anchor for call data at the ATGW. If determined, the ATGW of the UE's visited network is assigned as the anchor point of the call data.
- call data between the UE 100 and the UE 102 is transmitted and received through the Path A and the Path B.
- the e-node B When the UE 100 tries to move away from the coverage area of the e-UTRAN, the e-node B detects this and exchanges signaling with the RNC / node B via the MME and the MSC / MGW 110 (signalling 300 shown in FIG. 3). ST300 shown in 4). In ST 300, a data path in the CS network is prepared between node B and MSC / MGW 110, and when preparation is complete, MME instructs UE 100 to hand over to UTRAN (CS network) via e-node B. Is issued.
- the MSC / MGW 110 sends IMS signaling to the ATCF of the visited network of the UE 100.
- an instruction of path switching is issued from the ATCF to the ATGW in the area network where the UE 100 is located, and the call data transmission / reception destination of the ATGW is switched from the UE 100 to the MSC / MGW 110 (signaling 302 shown in FIG. 3. ST 302 shown in FIG. 4). That is, Path C is established.
- the ATCF transmits notification signaling (IMS signaling) to the SCC-AS (signaling 302 shown in FIG. 3; ST 302 shown in FIG. 4).
- the UE 100 exchanges signaling with the MSC / MGW 110 via the RNC / node B (signaling 304 shown in FIG. 3; ST 304 shown in FIG. 4). Thereby, Path D is established.
- the MSC / MGW 110 exchanges signaling with the P-GW / S-GW via the MME (signaling 306 shown in FIG. 3; ST 306 shown in FIG. 4). Thereby, Path B is deleted.
- SRVCC In the configuration of SRVCC in FIG. 1, for example, while UE 100 contracted by a Japanese mobile phone company roams to a mobile phone network in Europe, the CS network is in progress during a call with UE 102 also located in the same country in Europe. Even when the handover is performed, the IMS signaling between the MGW and the UE 102 is transmitted and received via Japan, and there is a problem that the signaling between the MGW and the UE 102 takes time.
- the MGW and the ATCF are usually provided close to each other in the same country. Furthermore, signaling is only performed between the MGW and the ATCF, and signaling with the UE 102 is not necessary. As a result, the time taken to switch data paths can be shortened.
- AMR adaptive multi-rate
- NB narrowband
- AMR adaptive multi-rate wideband
- WB wideband
- Non-Patent Document 4 there is also a codec used in a PS network (VoLTE), such as EVS (Enhanced Voice Service) described in Non-Patent Document 4.
- VoLTE PS network
- EVS Enhanced Voice Service
- the narrow band (NB: Narrowband) codec is a codec that performs encoding and decoding processing of a digital acoustic signal sampled at 8 kHz.
- a narrow band codec generally has a frequency band of 300 Hz to 3.4 kHz, the frequency band is not limited to this and may be in the range of 0 to 4 kHz.
- the wideband codec is a codec that performs encoding and decoding processing of a digital acoustic signal sampled at 16 kHz. Note that although a wideband codec generally has a frequency band of 50 Hz to 7 kHz, the frequency band is not limited to this and may be in the range of 0 to 8 kHz.
- a super wide band (SWB: Super Wideband) codec is a codec that performs encoding and decoding processing of a digital acoustic signal sampled at 32 kHz.
- the ultra wideband codec generally has a frequency band of 50 Hz to 14 kHz, but the frequency band is not limited thereto and is not limited as long as it is in the range of 0 to 16 kHz.
- 3GPP TS 23.216 v12.6.0 Single Radio Voice Call Continuity (SRVCC)”
- 3GPP TS 23.228 v12.0.0 IP Multimedia Subsystem (IMS); Stage 2”
- 3GPP TS 23.237 v12.6.0 IP Multimedia Subsystem (IMS) Service Continuity”
- 3GPP TS 22.813 v10.0.0 Student “Study of Use Cases and Requirements for Enhanced Voice Codecs for the Evolved Packet System (EPS)”
- EPS Evolved Packet System
- the codec used by the PS network is not supported by the CS network
- the codec used by the UE 100 is the CS network. Change to a supported codec.
- the first method is to perform transcoding in MSC / MGW or ATCF / ATGW.
- the second method is a method of changing the codec used in the UE 102 to the same codec as the UE 100 after the change.
- the former transcoding method requires that MSC / MGW or ATCF / ATGW support transcoding.
- the speech quality may be degraded due to transcoding.
- the latter method of changing the codec requires codec renegotiation by IMS signaling in order to change the codec of the UE 102.
- IMS signaling for path switching at the time of handover of the UE 100 terminates at ATCF, so IMS signaling for changing the codec of the UE 102 can not be sent.
- Patent Document 1 even when the eSRVCC scheme is used on the network side, it is detected whether or not the UE has a function of performing handover to CS, that is, whether or not the UE is compatible with SRVCC. Discloses a method in which the communication path is not anchored by the ATGW.
- Non-Patent Document 4 even in the eSRVCC method (even when IMS signaling is via ATCF), a method of treating it as normal SRVCC, that is, the communication route is not anchored by ATGW, and either A method is described in which, when a UE is handed over to a CS network, IMS signaling is transmitted / received to / from the other UE via the ATCF from the MGW (ATCF without media anchored in ATGW).
- whether or not IMS signaling is sent to the other UE is determined depending on whether the UE supports SRVCC regardless of the codec used by the UE.
- Non-Patent Document 4 does not describe in any case whether eSRVCC is treated like normal SRVCC.
- This disclosure makes it possible to change the codec of another terminal when one of the terminals in communication performs a handover involving a change of codec, and to execute the network node capable of continuing communication and the network node Provide a signaling processing method.
- the ATCF which anchors IMS signaling, checks the contents of the SDP offer / answer, compares the codec used at the start of the call with the codec used by the CS to which the UE can handover, and transcodes it to the ATGW. If you do not want to transcode at ATGW, or if you do not want to anchor the communication path at ATGW, select a method to treat as normal SRVCC, when handover to CS of UE occurs. Performs codec re-negotiation by transmitting and receiving an SDP offer / answer with IMS signaling again with the other UE.
- codec re-negotiation is performed by transmitting and receiving an SDP offer / answer with IMS signaling again with the other UE.
- One aspect of the network node according to the present disclosure is a network node having at least an ATCF function (Access Transfer Control Function) used for enhanced Single Radio Voice Call Continuity (eSRVCC), and is an SDP included in IP Multimedia Subsystem (IMS) signaling.
- ATCF Access Transfer Control Function
- IMS IP Multimedia Subsystem
- a reception unit that receives an offer or an SDP answer, an SDP analysis unit that acquires information on the SDP offer or a codec included in the SDP answer, a data storage unit, and a determination unit.
- the data storage unit includes information on codecs supported by an Access Transfer Gateway (ATGW) or an MGW (Media Gateway) of a neighbor (Neighboring), information of transcoding supported by the ATGW or the MGW of a neighbor, and a neighbor.
- ATGW Access Transfer Gateway
- MGW Media Gateway
- CS Circuit Switching
- a network node capable of changing the codec of the other terminal and continuing the communication, and a signaling processing method executed in the network node Can be realized.
- corresponds to SRVCC and it assumes that ATCF / ATGW has acquired the information.
- ATCF / ATGW acquires whether UE corresponds to SRVCC the means as disclosed by patent document 1 may be used.
- FIG. 7 is a block diagram particularly constituting an ATCF portion of ATCF / ATGW 320 according to the present embodiment.
- the receiver 700 receives IMS signaling and the like.
- the transmission unit 702 also transmits IMS signaling and the like.
- the IMS signaling includes not only IMS signaling that the communication terminal UE transmits and receives at the time of session setup, but also IMS signaling transmitted and received with the handover of the UE.
- the SDP analysis unit 704 analyzes the contents of SDP offers and SDP answers included in IMS signaling. For example, an SDP offer or an SDP answer is analyzed to obtain information of a voice codec used for a call.
- the data storage unit 706 stores the capability (capability) of the ATCF / ATGW 320 itself and the capability of the neighboring MGW. For example, information on codecs supported by ATCF / ATGW320 or MGW, information on codecs supported by neighboring CS networks, information on transcoding supported by ATCF / ATGW320 or MGW (combination of codecs that can be transcoded) Information etc. are stored.
- the information on the neighboring MGWs and the neighboring CS network may be acquired using means such as exchanging signaling messages directly by the ATCF / ATGW 320 and MGW via another network node, or manually manually in advance. May be stored.
- the policy storage unit 708 stores a policy related to service provision. For example, two UEs performing communication may use different codecs, transcoding may be performed by ATCF / ATGW 320 or MGW, or codecs used by two UEs performing communication may be unified and transcoding may not be performed, etc. Policy is stored.
- the determination unit 710 uses the data stored in the data storage unit 706 as a result of analysis by the SDP analysis unit 704 and the policy stored in the policy storage unit 708 to perform SDP for codec renegotiation from ATCF to the UE. Determine whether to enable the sending of offers. Specifically, it is determined whether to enable or not to change the codec by transmitting and receiving IMS signaling with the UE 102 by anchoring the communication at the ATGW or not at the ATGW.
- FIG. 8 is a sequence chart showing an example of session setup in the first embodiment of the present disclosure.
- the SDP offer added Invite message (IMS signaling) sent from the UE 100 is sent to the ATCF / ATGW 320 (exactly ATCF only) via another network node (not shown) (801).
- IMS signaling IMS signaling
- ATCF performs ATGW selection and resource allocation (802).
- the ATCF / ATGW 320 sends an Invite message with an SDP offer to the UE 102 via another network node (not shown) (803). At this time, the ATGW is designated as the communication partner of the UE 102.
- the UE 102 then sends an SDP answer with the IMS message to the ATCF / ATGW 320 via another network node (not shown) (804).
- the determination unit 710 of the ATCF / ATGW 320 that has received the SDP answer uses the contents of the SDP answer, the data stored in the data storage unit 706, and the policy stored in the policy storage unit 708 to communicate in the selected ATGW. It is determined whether to anchor (805). An example of the determination method of the determination part 710 is shown in FIG.
- the determination unit 710 first confirms what codec is selected in the SDP answer (ST 901).
- the codec selected in the SDP answer is a codec that can be used when the UE is handed over to the CS network (a codec supported by the neighboring CS network).
- codecs that can be used in the CS network if the conventional criteria for determining whether to anchor communications at ATGW (such as the criteria described in Patent Document 1) are met, the communications are anchored at ATGW and satisfied. If not, select not to anchor communication at ATGW. (Not shown).
- the codec selected in the SDP answer is not the codec that can be used when the UE is handed over to the CS network, that codec is supported by the ATGW or a neighboring MGW that can be used when the UE is handed over It is confirmed whether it is a codec (ST 902). If not supported, it is impossible to perform processing related to the codec, such as transcoding, so that the communication is not anchored by the ATGW, that is, when the UE is handed over to the CS network and the codec is changed. , Transmit and receive IMS signaling for codec renegotiation with UE 102, and select to be able to unify with codec UE 100 (ST 903).
- transcoding is not supported, it is selected not to anchor communication at ATGW (ST 903). Also, even if transcoding is supported, the policy is checked whether to allow transcoding (transcoding is used or not) (ST 905), and transcoding is not permitted. To not anchor communication at the ATGW (ST 903). That is, when the UE is handed over to the CS network and the codec is changed, it is selected to transmit / receive IMS signaling for codec re-negotiation with the UE 102 so as to be able to unify with the codec UE 100. Do.
- the ATGW determines whether all other conditions for anchoring communication are ready at the ATGW (ST 906). For example, if the selected codec is compatible with the codec supported by the neighboring CS, as described in Patent Document 2, without transmitting or receiving IMS signaling to / from the UE 102 (RTP payload format Check if the codec has the switching function to compatible mode (without session renegotiation for switching). If there is no function or there is no policy to use even if it has it, it is selected that the communication is not anchored by the ATGW (ST 903).
- a codec that has the function of performing operations without transcoding without transmitting / receiving IMS signaling to / from UE 102, and if there is a policy that uses that function, and other for anchoring communications at ATGW.
- IMS signaling for codec re-negotiation with the UE 102 is transmitted and received, and between the codec UE 100 and the UE 102. It is determined that there is no need to unify them, and ATGW anchors communication (ST 907).
- IMS signaling is transmitted and received such that the communication destinations of the UE 100 and the UE 102 become the selected ATGW, as described in Non-Patent Document 4.
- the ATCF / ATGW 320 again transmits an IMS message to the UE 102 as shown in FIG. 8 (806), and the communication destination of the UE 102 is changed to the UE 100 instead of the ATGW.
- the MGW or MGW or the like may not be compatible with the codec after the change. If the ATGW does not support or permit transcoding, or if there is compatibility, there is no need to transmit or receive IMS signaling with the UE 102 (RTP payload format switching to no session re-negotiation) to compatible mode Even if it does not support or permit the switching of H.264, it is possible to continue communication by transmitting and receiving IMS signaling between the ATCF / ATGW and the UE 102 and performing codec re-negotiation.
- FIG. 7 is a block diagram of the ATCF / ATGW 320 of the present embodiment, which is the same as that of the first embodiment.
- FIG. 10 is a sequence chart showing an example of session setup in the second embodiment of the present disclosure.
- the SDP offer added Invite message (IMS signaling) sent from the UE 100 is sent (1001) to the ATCF / ATGW 320 (exactly ATCF only) via another network node (not shown).
- the ATCF / ATGW 320 determines whether to determine whether to anchor communication at the ATGW from the SDP offer (1002). For example, in the determination unit 710 of the ATCF / ATGW, it is confirmed and determined whether the policy storage unit 708 has a policy for determining whether to anchor communication by the ATGW based on the contents of the SDP offer. If it is not determined from the contents of the SDP offer whether the ATGW anchors the communication, the determination is made from the SDP answer as in the first embodiment.
- FIG. 11 shows an example of the determination method of the determination unit 710 of the ATCF / ATGW 320 according to the present embodiment. That is, when judging by the SDP offer (ST 1101), the codec of the SDP offer is analyzed by the SDP analysis unit 704 (ST 1102). If the codecs analyzed at this time include ATCF / ATGW 320 or codecs not supported by the neighboring MGW (ST 1103), delete the codecs from the SDP offer and make them only supported codecs (ST Even when the UE 100 is handed over to the neighboring CS network, it is inquired of the policy storage unit 708 whether or not only the codec can continue communication without re-negotiating the codec with the UE 102 (ST1104).
- the ATGW When deleting, it is determined that the communication is anchored by the ATGW (ST1105). That is, the ATGW which anchors communication is selected and resources are allocated. Further, an SDP with the corresponding codec deleted is generated by the SDP analysis unit 704 or the like, and the AT GW is notified to the UE 102 by IMS signaling as a communication counterpart. Also, when receiving the SDP answer from the UE 102, the SDP answer is sent to the UE 100 by using the IMS signaling as the communication partner as the ATGW. On the contrary, when the codec is not deleted from the SDP offer, if the codec is selected, it is impossible to perform processing related to the codec such as transcoding, so it is determined that the ATGW does not anchor the communication ( ST 1106).
- IMS signaling is sent to the UE 102 with the UE 100 as a communication counterpart. Also, upon receiving the SDP answer from the UE 102, the UE transmits IMS signaling to the UE 100 using the UE 102 as a communication partner.
- the determination criteria (transcoding policy etc.) described in the first embodiment are applied to the ATGW. It may be determined whether to anchor the communication.
- Embodiment 1 determines whether to anchor communication (ST1107, ST1108, ST1109).
- the ATGW after receiving an SDP answer as in Embodiment 1, the ATGW determines whether to anchor communication or not, and if not anchored, the procedure for changing the communication partner of UE 102 from ATGW to UE 100 Can be omitted. Therefore, the time required for session setup can be shortened compared to the first embodiment.
- FIG. 7 is a block diagram showing a configuration of ATCF / ATGW 320 according to the present embodiment, which is similar to that of the first embodiment.
- FIG. 12 is a sequence chart showing an example of session setup in the third embodiment of the present disclosure and a case where the UE 100 performs handover to a CS network.
- the SDP offer added Invite message (IMS signaling) transmitted from the UE 100 is transmitted to the ATCF / ATGW 320 (exactly ATCF only) via another network node (not shown) (1201).
- IMS signaling IMS signaling
- ATCF performs ATGW selection and resource allocation (1202).
- the ATCF / ATGW 320 transmits an SDP offer-added Invite message to the UE 102 via another network node (not shown) (1203). At this time, the ATGW is designated as the communication partner of the UE 102.
- the UE 102 sends an SDP answer together with the IMS message to the ATCF / ATGW 320 via another network node (not shown) (1204).
- the ATCF / ATGW 320 that has received the SDP answer transmits an SDP answer to the UE 100 via another network node (not shown) as described in Non-Patent Document 4 (1205).
- the ATGW is designated as the communication partner of the UE 100. That is, the ATCF / ATGW 320 anchors communication at the ATGW without analyzing the SDP offer answer.
- Non-Patent Document 1 1206
- the MSC / MGW transmits an Invite message with an SDP offer to the ATCF / ATGW 320 as described in Non-Patent Document 4 (1207).
- the judging unit 710 of the ATCF / ATGW 320 that has received this message uses the contents of the SDP offer, the data stored in the data storage unit 706, and the policy stored in the policy storage unit 708 to transmit the codec from the ATCF to the UE. It is determined whether to enable transmission of the SDP offer for re-negotiation. Specifically, a determination is made as to whether to send IMS signaling (Invite message with SDP offer) to renegotiate the codec to the UE 102 (1208). An example of the determination method of the determination part 710 is shown in FIG.
- Determination section 710 first confirms whether the codec used by UE 100 before the handover is included in the codec selected in the SDP offer (ST1301, ST1302). If it is included, IMS signaling (SDP offer) is not sent to the UE 100, and communication is continued according to the method described in Non-Patent Document 4 without changing the codec.
- IMS signaling is transmitted / received to / from the UE 102 in the same manner as in Embodiment 1, and the SDP is again performed.
- Determine whether to unify the codec by exchanging offer and answer That is, it is checked whether the codec used by UE 100 before handover is supported by ATGW (ST 1303). If not supported, it is impossible to perform processing related to that codec such as transcoding Therefore, it sends IMS signaling to the UE 102 and selects codec re-negotiation (ST1304).
- the ATCF / ATGW checks whether transcoding is supported (ST1305).
- transcoding is not supported, IMS signaling is sent to the UE 102, and codec renegotiation is selected (ST1304). Also, even if transcoding is supported, the policy is checked whether to allow transcoding (ST1306). If the policy does not allow transcoding, IMS signaling is sent to the UE 102, and codec renegotiation is selected (ST1304). Also, even in the case of a policy that allows transcoding, IMS signaling is sent to the UE 102, and it is determined whether a condition that does not require codec re-negotiation is established (ST1307).
- the IMS signaling is not transmitted to and received from the UE 102 as described in Patent Document 2.
- the codec after the change is the codec before the change and ATCF / ATGW and UE102 even if they do not support transcoding in MGW or ATGW when they are incompatible, and even if they do not support switching with no session re-negotiation of the RTP payload format or if they are compatible.
- the communication can be continued by transmitting and receiving IMS signaling between them and re-negotiating the codec.
- the ATCF / ATGW 320, the MSC / MGW 110, and the SCC AS / CSCF have been described as one node.
- the present disclosure is not limited thereto, and the ATCF / ATGW 320, the MSC / MGW 110, and the SCC AS / CSCF may be configured of two or more separate nodes connected to each other by an interface. That is, the functions described above may be distributed to a plurality of nodes in each of ATCF and ATGW, MSC and MGW, and SCC AS and CSCF. Conversely, the functions of ATCF / ATGW 320 and MSC / MGW 110 may be implemented in one node.
- the present disclosure is not limited to this, and can be applied to codecs such as music, sound, and images.
- FIG. 8 to FIG. 13 show the operation (method) with hardware designed specifically, and install a program for executing the operation (method) of the present disclosure in general-purpose hardware. This also includes the case where it is realized by execution on a processor.
- Examples of the general-purpose hardware electronic computer include personal computers, various portable information terminals such as smart phones, and mobile phones.
- hardware specially designed includes not only finished products (consumer electronics) such as mobile phones and fixed phones but also semi-finished products and parts such as system boards and semiconductor devices.
- the network node of the present disclosure is useful for handling codecs used for music signals and the like and codecs used for image signals, as well as handling voice codecs.
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
Description
図7~図9を用いて実施の形態1を説明する。図7は本実施の形態のATCF/ATGW320のうち、特にATCF部分を構成するブロック図である。
図7及び図10~11を用いて実施の形態2を説明する。図7は本実施の形態のATCF/ATGW320を構成するブロック図であり、実施の形態1と同様である。図10は、本開示の実施の形態2におけるセッションセットアップの一例を示すシーケンスチャートである。
本実施の形態では、セッションセットアップ時にATGWで通信をアンカーする場合においても、UE100のCS網へのハンドオーバなどでUE102とのコーデックの再折衝が必要になった場合には、ATCF/ATGW320からUE102にIMSシグナリングを送る機能をATCF/ATGW320に持たせる。
700 受信部
704 SDP解析部
706 データ格納部
710 判断部
Claims (14)
- eSRVCC(enhanced Single Radio Voice Call Continuity)に用いるATCF機能(Access Transfer Control Function)を有するネットワークノードであって、
IMS(IP Multimedia Subsystem)シグナリングに含まれるSDP(Session Description Protocol)オファーまたはSDPアンサーを受信する受信部と、
前記SDPオファーまたは前記SDPアンサーに含まれるコーデックの情報を取得するSDP解析部と、
ATGW(Access Transfer Gateway)または近隣のMGW(Media Gateway)でサポートしているコーデックの情報、前記ATGWまたは近隣の前記MGWでサポートしているトランスコーディングの情報、および近隣のCS(Circuit Switching)網がサポートしているコーデックの情報の少なくとも一つを保持するデータ格納部と、
前記SDP解析部で取得した前記コーデックの情報、および前記データ格納部から読み出した情報を用いて、前記ATCFから通信端末へコーデックを再折衝するためのSDPオファーの送信を可能にするか否かを判断する判断部と、
を有するネットワークノード。 - 前記判断部における、前記ATCFから前記通信端末へコーデックを再折衝するための前記SDPオファーの送信を可能にするか否かの判断は、
前記ATGWで通話データをアンカーするか否か、または、
前記通信端末にコーデックを再折衝するための前記SDPオファーを送信するか否か、
の判断である、
請求項1記載のネットワークノード。 - 前記受信部でセッションセットアップの際に受信した前記SDPオファーまたは前記SDPアンサーに含まれる前記コーデックが、前記ATGWまたは近隣の前記MGWでサポートしているコーデックと一致しない場合、
前記判断部は、前記ATGWで通話データをアンカーしないと判断する、
請求項2記載のネットワークノード。 - 前記受信部でセッションセットアップの際に受信した前記SDPオファーに含まれる前記コーデックが、前記ATGWまたは近隣の前記MGWでサポートしている前記コーデックと一致しない場合において、
前記SDPオファーから前記コーデックを削除して送信する場合には、前記判断部は、前記ATGWで通話データをアンカーすると判断し、
前記SDPオファーから前記コーデックを削除しないで送信する場合には、前記判断部は、前記ATGWで通話データをアンカーしないと判断する、
請求項3記載のネットワークノード。 - 前記受信部でセッションセットアップの際に受信した前記SDPオファーまたは前記SDPアンサーに含まれる前記コーデックが、近隣の前記CS網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ATGWまたは近隣の前記MGWで前記SDPオファー又は前記SDPアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、
前記判断部は、前記ATGWで通話データをアンカーしないと判断する、
請求項2記載のネットワークノード。 - 前記受信部で前記通信端末のハンドオーバ時に受信した前記SDPオファーに含まれる前記コーデックが、前記ATGWでサポートしているコーデックと一致しない場合、前記判断部は、前記通信端末にコーデック再折衝のための前記SDPオファーを送信すると判断する、
請求項2記載のネットワークノード。 - 前記受信部で前記通信端末のハンドオーバ時に受信した前記SDPオファーに含まれる前記コーデックが、近隣の前記CS網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ATGWまたは近隣の前記MGWで前記SDPオファー又は前記SDPアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記判断部は、前記通信端末にコーデック再折衝のための前記SDPオファーを送信すると判断する、
請求項2記載のネットワークノード。 - eSRVCC(enhanced Single Radio Voice Call Continuity)に用いるATCF機能(Access Transfer Control Function)を有するネットワークノードにおけるシグナリング処理方法であって、
IMS(IP Multimedia Subsystem)シグナリングに含まれるSDP(Session Description Protocol)オファーまたはSDPアンサーを受信し、
前記SDPオファーまたは前記SDPアンサーに含まれるコーデックの情報を取得し、
ATGW(Access Transfer Gateway)または近隣のMGW(Media Gateway)でサポートしているコーデックの情報、前記ATGWまたは近隣の前記MGWでサポートしているトランスコーディングの情報、および近隣のCS(Circuit Switching)網がサポートしているコーデックの情報の少なくとも一つを取得し、
前記取得した情報を用いて、前記ATCFから通信端末へコーデックを再折衝するためのSDPオファーの送信を可能にするか否かを判断する、
シグナリング処理方法。 - 前記ATCFから前記通信端末へコーデックを再折衝するための前記SDPオファーの送信を可能にするか否かの判断は、
前記ATGWで通話データをアンカーするか否か、または、
前記通信端末にコーデックを再折衝するための前記SDPオファーを送信するか否か、の判断である、
請求項8記載のシグナリング方法。 - セッションセットアップの際に受信した前記SDPオファーまたは前記SDPアンサーに含まれる前記コーデックが、前記ATGWまたは近隣の前記MGWでサポートしているコーデックと一致しない場合、前記ATGWで通話データをアンカーしないと判断する、
請求項9記載のシグナリング方法。 - セッションセットアップの際に受信した前記SDPオファーに含まれる前記コーデックが、前記ATGWまたは近隣の前記MGWでサポートしている前記コーデックと一致しない場合において、
前記SDPオファーから前記コーデックを削除して送信する場合には、前記ATGWで通話データをアンカーすると判断し、
前記SDPオファーから前記コーデックを削除しないで送信する場合には、前記ATGWで通話データをアンカーしないと判断する、
請求項10記載のシグナリング方法。 - セッションセットアップの際に受信した前記SDPオファーまたは前記SDPアンサーに含まれる前記コーデックが、近隣の前記CS網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ATGWまたは近隣の前記MGWで前記SDPオファー又は前記SDPアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記ATGWで通話データをアンカーしないと判断する、
請求項9記載のシグナリング方法。 - 前記通信端末のハンドオーバ時に受信した前記SDPオファーに含まれる前記コーデックが、前記ATGWでサポートしているコーデックと一致しない場合、前記通信端末にコーデックを再折衝するための前記SDPオファーを送信すると判断する、
請求項9記載のシグナリング方法。 - 前記通信端末のハンドオーバ時に受信した前記SDPオファーに含まれる前記コーデックが、近隣の前記CS網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ATGWまたは近隣の前記MGWで前記SDPオファー又は前記SDPアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記通信端末にコーデックを再折衝するための前記SDPオファーを送信すると判断する、
請求項9記載のシグナリング方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP15792804.5A EP3145165B1 (en) | 2014-05-13 | 2015-04-20 | Network node and signaling processing method |
JP2016519094A JP6420328B2 (ja) | 2014-05-13 | 2015-04-20 | ネットワークノード及びシグナリング処理方法 |
US15/285,716 US9967782B2 (en) | 2014-05-13 | 2016-10-05 | Network node and signaling processing method |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201461992222P | 2014-05-13 | 2014-05-13 | |
US61/992,222 | 2014-05-13 | ||
JP2014138668 | 2014-07-04 | ||
JP2014-138668 | 2014-07-04 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/285,716 Continuation US9967782B2 (en) | 2014-05-13 | 2016-10-05 | Network node and signaling processing method |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015174018A1 true WO2015174018A1 (ja) | 2015-11-19 |
Family
ID=54479573
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2015/002134 WO2015174018A1 (ja) | 2014-05-13 | 2015-04-20 | ネットワークノード及びシグナリング処理方法 |
Country Status (4)
Country | Link |
---|---|
US (1) | US9967782B2 (ja) |
EP (1) | EP3145165B1 (ja) |
JP (1) | JP6420328B2 (ja) |
WO (1) | WO2015174018A1 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112640390A (zh) * | 2018-09-07 | 2021-04-09 | 苹果公司 | 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法 |
JP7523267B2 (ja) | 2020-07-10 | 2024-07-26 | 株式会社Nttドコモ | 通信制御装置 |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11089519B2 (en) * | 2016-04-13 | 2021-08-10 | Qualcomm Incorporated | Migration of local gateway function in cellular networks |
US11082455B2 (en) * | 2017-05-03 | 2021-08-03 | T-Mobile Usa, Inc. | Network gateway transcoder-utilization-aware session control |
US11509772B2 (en) * | 2018-11-13 | 2022-11-22 | Qualcomm Incorporated | Methods for increasing Voice-over-Internet Protocol (VoIP) network coverage |
WO2020122771A1 (en) * | 2018-12-10 | 2020-06-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Network node, entity and methods performed therein for handling a communication session in a communication network |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012054620A (ja) * | 2010-08-06 | 2012-03-15 | Ntt Docomo Inc | 移動通信方法及び移動通信システム |
WO2013072193A2 (en) * | 2011-11-14 | 2013-05-23 | Nokia Siemens Networks Oy | Method and apparatus for allocating a transfer function |
WO2013080471A1 (ja) * | 2011-11-30 | 2013-06-06 | パナソニック株式会社 | ネットワークノード及び通信方法 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102005050586B3 (de) * | 2005-10-21 | 2006-11-02 | Siemens Ag | Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz |
JP2009147692A (ja) * | 2007-12-14 | 2009-07-02 | Ntt Docomo Inc | 移動通信端末、交換局、蓄積装置、及び、メッセージ蓄積方法 |
US8204022B2 (en) * | 2008-02-20 | 2012-06-19 | Alcatel Lucent | Method of providing transcoding during voice-over-internet protocol handoff |
JP5140696B2 (ja) * | 2010-04-26 | 2013-02-06 | 株式会社エヌ・ティ・ティ・ドコモ | 移動通信システム及び移動局 |
JP2012105211A (ja) * | 2010-11-12 | 2012-05-31 | Ntt Docomo Inc | コアネットワークおよび通信システム |
CN104221429B (zh) * | 2012-04-17 | 2019-04-05 | 瑞典爱立信有限公司 | 利用活跃编解码器选择在接入网之间的呼叫的srvcc切换 |
-
2015
- 2015-04-20 WO PCT/JP2015/002134 patent/WO2015174018A1/ja active Application Filing
- 2015-04-20 JP JP2016519094A patent/JP6420328B2/ja not_active Expired - Fee Related
- 2015-04-20 EP EP15792804.5A patent/EP3145165B1/en active Active
-
2016
- 2016-10-05 US US15/285,716 patent/US9967782B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012054620A (ja) * | 2010-08-06 | 2012-03-15 | Ntt Docomo Inc | 移動通信方法及び移動通信システム |
WO2013072193A2 (en) * | 2011-11-14 | 2013-05-23 | Nokia Siemens Networks Oy | Method and apparatus for allocating a transfer function |
WO2013080471A1 (ja) * | 2011-11-30 | 2013-06-06 | パナソニック株式会社 | ネットワークノード及び通信方法 |
Non-Patent Citations (1)
Title |
---|
3GPP SA4-EVS SWG CONFERENCE CALL #26, AHEVS-253, 28 May 2013 (2013-05-28), XP008183131, Retrieved from the Internet <URL:http:// www.3gpp.org/ftp/TSG_SA/WG4_CODEC/Ad-hoc_EVS/ Docs/AHEVS-253.zip> [retrieved on 20150624] * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112640390A (zh) * | 2018-09-07 | 2021-04-09 | 苹果公司 | 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法 |
US11611909B2 (en) | 2018-09-07 | 2023-03-21 | Apple Inc. | Apparatus and method for signaling ran-assisted codec adaptation capabilities in IMS multimedia telephony sessions |
JP7523267B2 (ja) | 2020-07-10 | 2024-07-26 | 株式会社Nttドコモ | 通信制御装置 |
Also Published As
Publication number | Publication date |
---|---|
US20170026878A1 (en) | 2017-01-26 |
JP6420328B2 (ja) | 2018-11-07 |
EP3145165B1 (en) | 2019-10-16 |
EP3145165A4 (en) | 2017-04-26 |
EP3145165A1 (en) | 2017-03-22 |
JPWO2015174018A1 (ja) | 2017-04-20 |
US9967782B2 (en) | 2018-05-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10362514B2 (en) | Network node and communication method | |
US11647428B2 (en) | Communication terminal apparatus and communication method | |
US8957938B2 (en) | Method and apparatus for handing over a video conversation from packet switch domain to circuit switch domain | |
JP6420328B2 (ja) | ネットワークノード及びシグナリング処理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 15792804 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2016519094 Country of ref document: JP Kind code of ref document: A |
|
REEP | Request for entry into the european phase |
Ref document number: 2015792804 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2015792804 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |